トップ > SQS > Kinesis と SQS の使い分けについて調べてみた [後編：SQS の概要を把握する。]

Kinesis と SQS の使い分けについて調べてみた [後編：SQS の概要を把握する。]

SQS Amazon Kinesis
記事タイトルとURLをコピーする

本記事には前編がございます。
Kinesis と SQS の使い分けについて調べてみた [前編：Kinesis の概要を把握する。]

データを一時的に貯めておく役割を持つ Kinesis と SQS を比較してみようと思い、本記事を執筆しています。 それぞれを利用する場面、非機能面の充実度合い、料金面について主に触れて、比較できたら良いなと考えています。 何かのお役に立ちますと幸いです。 まずはそれぞれの機能や特徴について記載し、最後に比較をしていこうと考えています。 まだ理解が浅く、概要レベルのブログです。ご承知おきください。
後編 (本記事)では、 SQS の概要を記述し、比較しようと思います。

SQS

SQS は「メッセージング」という概念と一緒に語られることが多いサービスです。
まずは SQS の概要を確認するために、以下の動画、スライドを確認しました。

どれも内容が最高に素晴らしいです・・・。 「メッセージング」の概要については、一番上の AWSJ 白石さんの説明が非常にわかりやすいです。
SQS の機能詳細や、Kinesis との使い分けなどについては、真ん中の AWS Black Belt Online Seminar が詳しいです。
Sansan 様の事例は、実例の生々しさがありつつ、メッセージングで受けられる恩恵が明確に語られています。2017 年の資料なので、FIFOキューが東京にまだなかったり、若干古い情報もある点はご留意ください。差し引いても一見の価値ありです。
私としては、上から順番にこの 3 つを視聴することをおすすめします。（最後の Sansan 様の事例で感動的な気持ちになり、視聴した日はよく寝れました。）

メッセージングとは

せっかく動画を見て感動したので、自分の言葉と図で説明します。 私もエンジニアとして働いており、案件で SQS を提案させていただくことがありました。
その経験も踏まえて説明します。

ユーザーからの入力データを元に計算を行って、加工したデータを返却するシステムがあります。数年分の自分の健康診断のデータを入れると、10 年後の自分の健康診断の結果を予想で返してくれるようなシステムです。
インフラは以下の構成です。

処理フロー：

  1. ユーザーは （ALB の配下にある ECS サービス が提供する） WEB フォームにデータを入力します。
  2. ECS サービスは、加工処理を行う EC2 にデータを渡します。
  3. EC2 が処理結果を ECS サービスに返します。
  4. ECS サービスがユーザーに処理結果を返します。
  5. ユーザーは BI ツールを使って、加工したデータを確認します。

このサービスは、ユーザー数が徐々に増えていき、問題が出てきました。

問題点：

  1. 加工処理を行う EC2 の加工処理結果を待機する時間が長く、ECS サービスの CPU・メモリ負荷が大きい。
  2. ユーザー数が増えると、加工処理を行なっている EC2 の CPU や メモリが枯渇し、処理時間が長くなる。EC2 のスペックを上げたり台数を増やすと利用料金も上がる。
  3. RDS はライターの台数を増やせないため、スペックを最大にまで上げている。性能のボトルネックになっている。

そこで問題解決のために、SQS を使ったメッセージングの仕組みを入れてみます。
ECS サービスが EC2 にデータを渡すのではなく、SQS にデータを入れて、ユーザーにレスポンスを返すようにします。

これで、ECS サービスは EC2 の加工処理結果を待機することから解放され、ECS サービス の CPU や メモリの使用量が減りました。
それから、EC2 は 一定の間隔で SQS から一定数のデータを取得し、加工処理をするようにします。

EC2 は一定間隔で一定数のデータを処理するため、ユーザーが増えても同じペースでデータを処理します。
EC2 はユーザー数の増加に応じてスペックを上げたり台数を増やすことから解放されました。EC2 の CPU や メモリの使用量が減りました。
RDS に関しても、EC2 からのデータを一定の間隔で受け取るので、CPU や メモリの使用量が減り、スペックを下げることができました。 また、一定間隔で一定数処理するため、インスタンスの CPU やメモリを効率的に使えるようになりました。混雑時間帯以外で CPU や メモリ の余剰が発生することもなくなりました。
混雑時間帯のデータは、その後の時間帯にまたがって処理しています。

このようにして、1 つのサービスだったものは 2 つの疎結合なサービスに分割されました。

どちらかのサービスを止めた場合にも、片方が動き続けることができます。
WEB サービスはユーザー数の増加に応じて適切に台数を増やすことができる、軽量なコンテナです。
データを加工するサービスは、一定のリソースを効率よく使ってデータを処理します。
中間の SQS はデータを無制限に置くことができます。(最大保存期間は 14 日。)また、SQS のデータは複数のデータセンターに重複して保存しているため、冗長化もバッチリです。

ユーザーは処理結果を BI ツールで見ることができます。
混雑時間帯は、加工された結果が見えるまでに時間がかかることがあります。(結果整合性) これは許容しないといけません。

メッセージングにより、異なる性質の処理を分割して疎結合にして、サーバーリソースを効率よく柔軟に、運用性を高めて使うことができます。
その代わり、データが反映されるまでのタイムラグ (結果整合性)を許容したり、処理結果を通知する仕組みなどの考慮が必要になることもあります。

以上、メッセージングの説明でした。
実際の現場ではデータ加工処理をする EC2 を Auto Scaling にして、より柔軟にデータ処理したり、更なる性能面の工夫をしています。

SQS の特徴

Kinesis との違い

  • ストリーミングデータは Kinesis 、メッセージは SQS
  • データの送信者と受信者
    • Kinesis
      • 送信者は、IoT センサー (のデータ)、スマホアプリ (から送信する画像)、サーバー (のログ) など
      • 受信者は、ストレージ (S3)、データベース (DynamoDB、Redshift)、可視化ツール (OpenSearch、Tableau) など
    • SQS
      • 送信者は、コンピューティングサービス (Lambda, ECS , EC2) など
      • 受信者は、コンピューティングサービス (Lambda, ECS , EC2) など

参考リンク

まとめ

概要レベルで SQS と Kinesis を調べてみました。
それぞれの違いがとてもよくわかり、使いどころもわかりました。
こういったマネージドサービスを利用して、自分で何か作ってみても面白そうに思いました。
メッセージングについては、自分が過去に作ったサービスの構成を再レビューしてみるきっかけにもなりました。
調べてみて、素晴らしい資料や、尊敬できるエンジニアをたくさん知ることができ、感謝感謝の時間でした。

余談

山梨はもう気温が 1 桁で震えています。
誰かと会議をするたびに服装について、つっこまれます。

山本 哲也 (記事一覧)

カスタマーサクセス部のエンジニア（一応）

好きなサービス：ECS、ALB

趣味：トレラン、登山（たまに）