雲の呼吸参ノ型~AWS設計の勘所：マネージドサービス・後編~

asada

作成: 2020.10.21 更新: 2020.10.20

はじめに
続・マネージドサービスの利用
続・代表的なマネージドサービスとその用途
最後に

はじめに

データイノベーション部浅田です。

人気漫画「鬼滅の刃」に仮託して、「雲(クラウド)の呼吸」と題しまして、AWS(Amazon Web Services)を用いたアーキテクチャ設計の勘所を数回にわけて書いていきたいと思います。

なお、AWSに関するサービス名に関しては、この記事内で初出時は正式名称をつけ、以降は明確な場合は省略系を用いる方針で記述しています。

第三回目は「マネージドサービス・後編」です。

続・マネージドサービスの利用

前編で登場したハンニバルが戦った第二次ポエニ戦争（通称ハンニバル戦争）の前半のハイライトは何と言っても「カンナエの戦い」です。空前絶後の大勝利を納めたハンニバルですが、その後の戦況は徐々にローマ優勢に傾いていきます。原因の一つにローマの将軍スキピオ(大スキピオ)がカルタゴ優勢の要の一つであった「ヌミディア騎兵」を自軍に組み込んだということがあります。

「ヌミディア騎兵」は当時地中海世界最強の騎兵と目されていましたが、ハンニバルの騎兵戦術の要でもありました。スキピオはこれを味方に組み入れることで、歩兵戦術主体であったローマ軍に騎兵戦術を行える基盤をあっという間に整えました。そして、後半のハイライト「ザマの戦い」で、スキピオは攻守ところを変えて「カンナエの戦い」を再現、カルタゴ軍に勝利します。

AWSのマネージドサービスは、IT企業においてトップレベルにあると言っても過言ではないAWSの技術の粋が集められています。それらを利用することで、トップレベルの機能を利用することができるようになります。さらに、マネージドサービスを利用することで空いたリソース（手間・時間）を自社の独自の強みの構築に集中することができるようになります。

続・代表的なマネージドサービスとその用途

Amazon CloudWatch

CloudWatchはシステム監視向けのマネージドサービスになります。

CloudWatchは大きくわけると2通りのサービスになっていて、

メトリクス(プロセスの数やリソースの使用状況の収集)
ログ(アプリケーションのログの収集)

があります。

メトリクス

可視化によって、人間が現在のリソースの状況を把握するのにも使えますし、ある閾値を超えたら、Amazon SNSを経由してメールを送信したり、HTTPのエンドポイントにリクエストを投げたりするなどができます。また、Lambda経由でSlackに通知を行うことも可能です。第一回で出てきたAWS AutoScalingもこれらのメトリクスの値を元に、スケーリングを制御します。

サービスによって様々なデフォルトのメトリクスが提供されますが、CloudWatchエージェントを使用したり、直接送信することで好きなメトリクスを収集することもできます。たとえば、ある特定の機能の使用回数などをアプリケーションからCloudWatchになげることによってCloudWatchで一元管理を行うことができます。

ログ

アプリケーションのログの保存先として使用できます。コスト面ではS3にログを保存するほうが費用対効果は高いですが、検索が可能であったり、特定の文言の出現回数をメトリクスとして可視化できたり（もちろんその結果として通知などもできます）しますし、LambdaやAWS Fargateなどのサーバレスサービスをはじめとして、AWSのいくつものサービスのログの出力さきともなっています。

メトリクス同様、CloudWatachエージェントなどを利用することで、好きなログを収集することが可能です。

Amazon SES

メールによる通知は、会員登録であったり、メールマガジンであったり、はたまた障害通知であったり、ユーザへの連絡手段として昔から一般的に用いられています。

ですが、メール通知を行うためにメールサーバを運用することは、そう簡単な話ではありません。OB25問題に代表されるように、古くからある仕組みのために問題を抱えているので、迷惑メールの温床にならないように注意して運用する必要があります。

そこで、SESを使用することでメールサーバを運用することなく、システムからメールを送信することができるようになります。

AWSではメールサーバを運用して25番ポート（SMTP通信に使用するポート）でメールを外に送る際には、事前申請が必要になりますが、SESを使用することでその問題も回避できます。

SNSでもメール通知を行うことはできますが、SNSは事前にサブスクリプションを行う必要があるので、システム管理者への通知には使えますが、一般ユーザへの通知には向いていません。

Amazon EMR & AWS Glue & Amazon Athena

Hadoop、Spark、 Hive、HBase、Flinkなどの分散処理フレームワークの実行環境のためのマネージドサービスです。ユーザはアプリケーションの処理を作ることに集中できます。

タスクノードにスポットインスタンスを使用するよう設定できるので、コスト面などでメリットを受けられます。同時に、EMRFSを使用することで、処理結果などをS3に保持することができ、処理が必要ないときにはEMRクラスターを削除するなど、柔軟な運用を行うことができるようになります。

また、EMRはインスタンスなどをある程度意識する必要がありますが、分散処理フレームワークの技術をサーバレスにより利用できるサービスもあります。

例えば、GlueはSparkによるETLをサーバレスに実行できるサービスであり、AthenaはPrestoライクに、S3のデータをクエリで検索、加工することができます。

Amazon Kinesis Data Streams & Amazon Kinesis Data Firehose & Amazon Kinesis Data Analytics

大規模データをリアルタイムに処理するためのマネージドサービスがKInesisシリーズです。

ビッグデータの時代と言われるように、スマートフォン、IoTデバイス、各種センサーなどから絶え間なくデータが生成されています。それらを従来のバッチ処理の手法では処理しきれなくなり、常にデータが生成されるなら常に処理し続ける、というのがストリームデータ処理の考え方ですが、そのための基盤として利用できるのがKinesisシリーズになります。

Kinesis Data Streams

その中でもKinesis Data Streamsは、ストリームデータをもっとも柔軟に扱えるサービスになります。

データをストリームに投入するプロデューサーと、ストリームからデータを取得して処理するコンシューマーに分かれて処理を行うので、SQS同様にシステムを疎結合に保てるというメリットもあります。あと、コンシューマーを複数用意することで、一つのデータに対して複数の処理を行えるので、かたやデータ変換し、かたやS3にデータ保存し、みたいなことも可能です。なので、あとから機能追加が行いやすいというメリットにもなります。

Kinesis Data Firehose

リアルタイム性では若干劣るもののS3、Amazon Redshift、Amazon Elasticsearch Serviceへのデータ投入など、投げられたデータを保存する場合には、Kinesis Firehoseが威力を発揮します。Streamsがストリーム領域に応じて一定金額がかかるのに対し、Data FIrehoseは処理されたデータに対しての課金であるのに加えて、コンシューマの処理を実装する必要がありません。また、ビッグデータ処理のデータ形式としてよく使われるParquetやORCといったデータ形式にも対応しているので、ビッグデータ処理のためのデータ収集のサービスとしても優れています。

Kinesis Data Analytics

Kinesis Data Analyticsはストリームに対して、標準SQLでデータを集計、処理することができるサービスになります。Streamsがデータを逐次的に処理するのに対して、Analyticsはストリーム全体（および期間などで絞った一部）に対して、一括でデータ処理を行えるという点がことなります。「まさに今」のデータに対して、集計、可視化したいなどの用途に向いています。

最後に

以上、AWS上で設計を行う際に利用できるマネージドサービスの勘所でした。ここで紹介したのはマネージドサービスのごく一部で、この他にもAWSには便利なマネージドサービスがたくさんあります。それらを有効に活用することで、開発のコストも抑えつつ、スピーディにサービスを提供することができるようになるはずです。