【AWS】SAA資格取得のための学習用備忘録(アプリケーションサービス)

AWSのアプリケーションサービス

AWSには、EC2やRDS、VPCといったIaaSやPaaSのみならず、SaaSと呼ばれるようなアプリケーションサービスも積極的に展開している。

AWSを利用してより効率的にシステムを構築運用するには、アプリケーションサービスを上手く活用することが鍵となる。

試験の観点からも、コスト面や可用性に優れたシステムを構築する場合、アプリケーションサービスが鍵となる。

AWSのアプリケーションサービスに共通する基本的な考え方

AWSには数多くのアプリケーションサービスがあるが、基本的な考え方は共通している。

多くのユーザーが利用する汎用的なサービスを、AWSの大規模なリソースを利用して開発・運用することにより、低コストかつ高品質なサービスが提供できるという点。

ここで重要なのは、AWSのアプリケーションサービスはAWSが提供する多数のサーバーリソース上に構成されている点。

また、サーバーとアプリケーションのメンテナンスはAWSが行う。

このため、自分で冗長化構成をとるよりも、多くの場合でコスト面でも安定性でも優れている。

アプリケーションサービスとしてフルマネージドサービスを利用している場合、そのサービスの制約以外では冗長性や可用性は考えなくても良い前提になっている。

この章では、代表的なアプリケーションサービスを確認していく。

★AWSのアプリケーションサービスはAWSのサーバーリソース上に構築されており、サーバーとアプリケーションのメンテナンスはAWSに任せておける。そのため、コスト面でも安定性の面でも、自身で構成するより優れている

SQS

SQSは、AWSが提供するフルマネージドなメッセージキューイングサービス。

AWSのサービス群の中では最古のもので、2004年からサービスインしている。

これはAWSの中核機能であるEC2やS3の提供開始より前で、このことからもシステム間の連携の中でキューが果たす役割の大きさがわかる。

SQSの機能としては、キューの管理とメッセージの管理の2つがある。

キューとは、メッセージを管理するための入れ物のようなもので、基本的には利用開始時に作成すれば管理する必要はなく、エンドポイントと呼ばれるURLを介して利用する形になる。

キューの管理機能としては、キューの作成・削除の他に、動作属性などの詳細な設定がある。

メッセージの管理機能としては、キューに対するメッセージの送信・取得と処理済みのメッセージの削除がある。

それ以外にも、複数のキューをまとめて処理するバッチ用のAPIや、処理中に他のプロセスから取得できなくするための可視性制御のAPIもある。

StandardキューとFIFOキュー

SQSのキューには、StandardキューとFIFOキューがある。

SQSではベストエフォートのために、もともとメッセージの配信順序は保証されていなかった。

それが、2016年11月に配信順序が保証されるFIFOキューが登場したことで、従来のキューはStandardキューと呼ばれるようになった。

Standardキューでは、取得のタイミングによって同一のメッセージが2回配信される可能性があった。

そのため、利用するシステム側で同一のメッセージを受信しても影響がない作り方(冪等性)を保証する必要があった。

FIFOキューの場合は、同一メッセージの二重取得の問題も解消されている。

キューとしての使いやすさは、StandardキューよりもFIFOキューの方が優れている。

ただし、FIFOキューは配信順序の保証のために、Standardキューより秒あたりの処理件数が劣っている。

Standardキューは、1秒あたりのトランザクション数がほぼ無制限なのに対し、FIFOキューの1秒あたりのトランザクションはバッチ処理なしで300件、バッチ処理ありで3000件に限定されている。

★Standardキューはメッセージの配信順序を保証せず、同一のメッセージが2回配信される可能性がある

★FIFOキューはメッセージの配信順序を保証する。秒あたりの処理件数はStandardキューに劣る

ロングポーリングとショートポーリング

キューのメッセージ取得方法として、ロングポーリングとショートポーリングがある。

両者の違いは、SQSのキュー側がリクエストを受けた際の処理にある。

デフォルトのショートポーリングの場合、リクエストを受けるとメッセージの有無にかかわらず即レスポンスを返す。

これに対してロングポーリングの場合は、メッセージがある場合に即レスポンスを返すことは同じだが、メッセージがない場合は設定されたタイムアウトのギリギリまでレスポンスを返さない。

ショートポーリングの方がAPIの呼び出し回数も多くコストが高くなる。

複数のキューを単一スレッドで処理するような例外的なケース以外では、ロングポーリングを利用することが推奨されている。

可視性タイムアウト

メッセージは、受信しただけでは削除されない。

クライアント側から明示的に削除指示を受けた時に削除される。

そのため、メッセージの受信中に他のクライアントが取得してしまう可能性がある。

それを防ぐために、SQSには同じメッセージの受信を防止する機能として可視性タイムアウトがある。

可視性タイムアウトのデフォルトの設定値は30秒で、最大12時間まで延長できる。

遅延キューとメッセージタイマー

メッセージの配信時間のコントロールとして、遅延キューとメッセージタイマーという2つの機能がある。

遅延キューは、キューに送られたメッセージを一定時間見えなくする機能。

これに対してメッセージタイマーは、個別のメッセージに対して一定時間見えなくする機能。

両者とも、メッセージ配信後すぐに処理されると問題がある場合に利用する。

デッドレターキュー

デッドレターキューは、処理できないメッセージを別のキューに移動する機能。

指定された回数(1~1000回)処理が失敗したメッセージを通常のキューから除外して、デッドレターキューに移動する。

データ上あるいはシステム上の理由から必ず失敗するジョブがある場合、これらはキューに残り続ける。

デッドレターキューは、このような事態を防ぐのに有効。

デッドレターキューをうまく使うと、アプリケーション側の例外処理を大幅に簡素化できる。

メッセージサイズ

キューに格納できるメッセージの最大サイズは256KB。

文字列の情報には十分なサイズだが、画像情報などを扱うには足りない。

SQSでは、大きなサイズのデータはS3やDynamoDBに格納し、そこへのパスやキーといったポインター情報を受け渡すことで対応する。

SWFとStep Functions

システム開発をする際に必ず出てくるのが、複数の処理間の関連性。

単純に1→2→3と処理が順番に流れてくるものもあれば、1→2→3 or 4といったように処理結果によって分岐する場合もある。

このような一連の処理の流れをワークフローと呼ぶ。

ワークフローの中には、システム間の連携のみならず、人による処理が介在することもある。

AWSのワークフローサービス

AWSにはワークフローのサービスとしてSWFとStep Functionsがある。

Step FunctionsのワークフローエンジンはSWFを利用していると言われている。

そのため、一部の機能でStep Functionsがカバーしていない部分もあるものの、ワークフローの動作としては両者はほぼ同じことができる。

Step FunctionsとSWFの違いは可視化の機能。

Step Functionsには、ワークフローを可視化して編集できる機能がある。

とても難解なサービスであるSWFより、Step Functionsははるかに容易にワークフローを構築できる。

新規でワークフローを作る場合は、基本的にStep Functionsを利用する。

両者は、分散処理や並列処理が可能で、かつSQSのStandardキューと違って1回限りの実行保証がついている。

処理の順序性も保証されている。

また、システムの処理途中で人間系の処理が入る場合には、かなりの確率でAmazon Mechanical Turkと併用して利用されることになる。

Mechanical Turkはクラウドソーシングのサービス。

★SWFとStep Functionsはワークフロー(一連の処理の流れ)を制御するサービス。両者はほぼ同等の機能を持つが、Step Functionsには可視化の機能があり、SWFよりも使いやすい

SNSとSES

管理者同士の連携や利用者への通知など、複数のユーザーにシステムの状態を知らせる際に重要な役割を果たすのがSNS。

SNSはプッシュ型の通知サービス。

マルチプロトコルのため、複数のプロトコルに簡単に配信できる。

2020年12月現在、利用できるプロトコルはSMS、email、HTTP/HTTPS、SQSに加え、iOSやAndroidなどのモバイル端末へのプッシュ通知、Lambdaとの連携などが利用できる。

メッセージをプロトコルごとに変換する部分はSNSが行うため、通知する人はプロトコルの違いを意識することなく配信できる。

SNSは、システムのイベント通知の中核を担う。

SQSやCloudFrontなどと組み合わせて、システム間の連携や外部への通知などに利用する。

SESは、Eメール送信のサービス。

SMTPプロトコルを利用して、あるいはプログラムから直接Eメールを送信する際に利用する。

★SNSはプッシュ型の通知サービスで、システムのイベント通知の中核を担う

★SESはEメール送信サービスで、SMTPプロトコルを利用する

SNSの利用について

SNSはトピックという単位で情報を管理する。

システム管理者は、メッセージを管理する単位でトピックを作成する。

トピックの利用者としては、通知する人(Publisher)と通知される人(Subscriber)がいる。

Subscriberは、利用するトピックおよび受け取るプロトコルを登録する。

これを購読と呼ぶ。

Publisherはトピックに対してメッセージを配信するだけで、Subscriberのこともプロトコルのことも意識する必要はない。

SNSを使ったイベント通知

SNSは、AWS上でイベントが発生した時の通知を一手に引き受ける。

そのためアーキテクチャ設計上、SNSは非常に重要な役割を果たす。

イベントの種類には様々なものがあるが、例えば次のようなものがある。

・リソースの設定、状態を評価するAWS Configでルールに反している使われ方が発見された

・CloudWatchでCPU、ネットワークなどのメトリクスを監視しているときに閾値を超えた

SNSは、メールやモバイルプッシュで人間に通知することも可能で、SNSからLambdaを呼び出してプログラムに対処させることも可能。

プッシュ型の通知が必要なアーキテクチャを問われた場合は、まずSNSが使えるかどうかを検討する。

SES

SESはEメール送信サービス。

SMTPプロトコルやAPIを通じたメール送信の他に、Eメールを受信し、S3に保存することも可能。

SESの特徴は高い配信性能にある。

近年のメール環境は、ウイルスメールやスパムメールの送信者など、悪意を持った送信者によって危険に晒されている。

そのため、メールサーバーを運営するインターネットサービスプロバイダー(ISP)や通信キャリア、個人・企業などは、安全性を高めるために様々な手段を講じている。

例えば、特定のIPから短期間のうちに大量のメールが送信された場合に遮断する。

あるいは、IPアドレスやドメインごとに過去の行動履歴を調べ、評価(レピュテーション)を与え、評価が低いIPアドレスからの送信を受け付けない、ということもある。

さらに、それらの情報をDB化して全世界で共用することにより、防御効果を高めている。

SESは、こういった状況に対処して信頼性の高いメールだけを配信するための、いくつもの機能を備えている。

・送信時にウイルスやマルウェアを検出してブロックする機能

・送信の成功数や拒否された数を統計的に処理し、配信不能や苦情を管理する機能

・Sender Policy Framework(SPF)やDomainKeys Identified Mail(DKIM)といった認証機能

SESは、信頼性を保つために利用者にもいくつかの制約を課している。

まずSESは、登録済みのメールアドレスもしくはドメインからのみ送信可能。

登録の際には、送信元として正式な所有者であること証明する必要がある。

また、利用するには次の3つの条件をクリアしなければならない。

・Bounce Mail(配信不能メール)の比率を5%以下に保ち続ける

・苦情を防ぐ(0.1%未満)

・悪意のあるコンテンツを送らない

メールサーバーの運用は年々負荷が高いものとなっており、SESはその運用に必要な機能を備えていると言える。

まとめ

アプリケーションサービス

・AWSのアプリケーションサービスはAWSのサーバーリソース上に構築されており、サーバーとアプリケーションのメンテナンスはAWSに任せておける。そのため、コスト面でも安定性の面でも、自身で構成するより優れている

・SQSはフルマネージドなメッセージキューングサービスで、キューとメッセージを管理する

・SWFとStep Functionsはワークフロー(一連の処理の流れ)を制御するサービス。両者はほぼ同等の機能を持つが、Step Functionsには可視化機能があり、SWFよりも使いやすい

・SNSはプッシュ型の通知サービスで、システムのイベント通知の中核を担う。様々な通信プロトコルに対応している

・SESはEメール送信サービスで、SMTPプロトコルを利用する。様々な防御機能を備えており、高い配信性能を誇る