Ch.9 アプリケーションサービス

AWS SAA対策

AWSでのアプリケーションサービスは、外部のアプリケーションをEC2インスタンスなどを利用して自前で運用することも可能である。

AWSのマネージドサービスを利用すると、AWSインフラ上に冗長性とコスト最低化が図られた状態でサービスが用意される。AWSの認定試験では、フルマネージドのアプリケーションサービスを利用している限り冗長性や可用性は考えなくて良いものとして問題を解くことが出来る。

SQS

Amazon Simple Queue Serviceの略。EC2やS3よりも前のサービス。メッセージングキューイングとは、ホストコンピュータが主役となっていた時代にシステム間を接続する目的で使われたサービスである。

若手が知らない昔の技術MQ、クラウドではホットだ | 日経クロステック（xTECH） (「若手が知らない技術」として紹介されているのがなんだか象徴的。)

キューには【エンドポイント】を介してメッセージがキューから出し入れされる。キューにはStandardキューとFIFOキューが存在する。

Staandardキューでは同じメッセージが2回送信される可能性が存在した。メッセージを重複して配信されても問題ないような仕組みは受信側で整備しなくてはならなかった(冪等性という)。

一方FIFOキューは、同じメッセージを2回送信する可能性がなくなった上、(名前の通り)順序を保証した送信に対応するようになった(Standardキューではこれが無かった)。その分FIFOキューではパフォーマンスに制限がかかる。

なお、キューに格納できるメッセージのサイズは小さいので、画像などを連携する場合はS3などのアドレスを連携することになる。

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

SQSではキューからメッセージを呼び出すために叩いたAPIの回数に応じた従量課金制で設定されているので、APIを叩く回数が少ないほど安くなる。

SQSのメッセージの返し方はロングポーリングとショートポーリングに分かれる。ショートポーリングの場合、普通のAPIと同じく、リクエスト側に即レスポンスが送られる。一方ロングポーリングの場合、メッセージがキューに存在しなかい場合に限り、タイムアウトギリギリまでレスポンスが返らない。

そのため、キューにメッセージが貯まっていない場合はAPIを叩く間隔が間延びし、その分叩く回数も少なくなる。もちろんアプリケーション側の実装によっては、この実装は上手く行かない。

Amazon SQS ロングポーリングを理解する - Qiita

可視性タイムアウト

キューへのメッセージリクエストが複数になる場合を想定する。

メッセージは相手側が受信するだけでなく、受信完了(≒削除指示)を受けるまではキューから削除されない。 しかし、送信してから受信完了の合図を受け取るまでに、別のノードが同じメッセージを受信してしまう可能性がある。

このため送信してから受信完了の合図があるまでは、他のノードがそのメッセージを受信できなくなる仕組みが存在し、これが「可視性タイムアウト」である。

Amazon Simple Queue Service の可視性タイムアウトってなぁに? | DevelopersIO

当然だがいつまでも「受信完了」の合図が返却されない場合は、他のノードに受信してもらいたいので再度可視化する必要がある(送信してから受信完了の合図を待つまでに、相手のノードがダウンしている可能性がある)。このため、送信してから受信完了の合図を受け取るまで、そのメッセージを他のノードが受け取れないようにする時間は限られている。これが「タイムアウト」と呼ばれる所以。

このタイムアウトを「今処理中なので受信完了の合図は待ってください。まだ他のノードにこのメッセージを見せないでください。」という意味で期間延長を申し出るのが、「ハードビート」と呼ぶ(まだ生きています、の意味)。

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

メッセージがキューに入ってから一定期間見えなくなる(寝かされる)機能のこと。 遅延キューとメッセージタイマーの違いは、その対象が個別のメッセージが・メッセージ全体かになる。

デッドレターキュー

受け取り側が処理できない（受信完了の合図を送れない）メッセ―ジを通常のキューから外して別のキューに移動する仕組み。移動する対象となるメッセージの失敗回数をこちらで指定することが出来る。

これを利用すると、受信側のアプリケーションの例外処理を簡素に保つことが出来る。

SWF と Step Functions

ワークフローとはなんだ、と思っていたけどAJSのように、各JOBを順番に実行しつつ一部に処理の分岐も入れられるような仕組みをワークフローというらしい。

雑な言い方をすれば、個々のLambda関数を簡単につなぐためのAWSサービスになります。

Step Functionsを使って初めてループや分岐をやってみた！ | DevelopersIO

とのこと。

Simple Workflowを名乗っているがこちらの方がサービスとしては複雑で、Step Functionの方がGUIで操作が可能なので好まれる。

ワークフローには、途中で人間に判断を任せるJOBを作成することが出来る。人間に判断を任せる処理を食らうおソーシングすることも出来、これはAWSのサービスとしてMechanical Turkという名前で提供されている。

SNSとSES

システムの管理者のみならシステムのサービス利用者に対しても通知を送信することができるのが、Amazon　Simple Notification Serviceである。

システム管理に用いる場合はSNSはCloudWatchなどと連携されて、システムの監視に紐付けられる。

モバイルプッシュ通知 - Amazon Simple Notification Service

各デバイスにPush通知を送る場合は、AWS自体がそのサービスを提供するわけではなく、他の通知サービスに乗っかるような形で通知サービスを提供している。

システム監視においてSNSでの通知が発生した場合、Push通知で人間に対処させることも出来るが、SNSをトリガにしたlambdaの呼び出し等も可能。

Amazon SNS での Lambda の使用 - AWS Lambda

SESはAmazon Simple Email Serviceは文字通りメールサービスで、SNSと異なり「受信」も可能。

メールサービス各社はスパムメールが配信されたIPアドレスのブラックリストを世界中で共有するなど、スパムメール対策を行っており、自分の配信メールが受信者のISPにスパムとして認証されないことが配信性を高める基準になる。

Amazon SESは利用者(配信者)のメールの内容をスキャンし、各社ISPがスパムと認定する基準を満たしていないかを確認する。

また、利用者は配信メールの配信不能メールを5%以下に抑えること、苦情を防ぐことなどが求められ、結果としてSESから送信されるメールの配信性が高くなっている。また登録済のメールアドレスからしか送信することが出来ないうえ、送信元の正式なメールアドレスであることをAWS側に証明することが求められる(つまりスパムメールを送るためにSESを使うのではないと証明する必要がある)。