AWS構成の基本をユースケースごとに学ぼう。AWSの中の人がサンプルをもとに解説する

── まずは半場さんに、データ分析系のアーキテクチャ構築法について伺います。データを収集・分析して各種の施策に結びつけたいと考えるIT企業は多いですが、いきなり大規模なデータ分析基盤を構築しようとすると、苦労も大きいですしコストも相当にかかります。スモールスタートで基盤を構築するならば、AWSのサービスを用いてどのようなアーキテクチャを組むべきでしょうか？

半場　アーキテクチャを組む前に、念頭に置いていただきたいことがあります。分析基盤のみならず、すべてのワークロードにおいて、まずは「何を目的にしてアーキテクチャを構築するのか」を深く考えてください。分析結果からどのような洞察を得たいのかを考慮し、そこから逆算して必要なデータソースを特定する必要があります。

そのうえで、分析基盤に求められるリアルタイム性やかけられる予算、サービスの成長率、今後の展望といった各種指標を洗い出し、データパイプラインをデザインしていきます。今回のインタビューの「スモールスタートなデータ分析基盤」というテーマに則り、その要件を達成するための複数パターンのアーキテクチャを用意しました。まずはプランAです。

このアーキテクチャプランは、スモールスタートできるうえに柔軟性が高く、分析データを多種多様な用途に活用しやすいことが特徴です。まず、FluentdのようなLog CollectorのプラグインやKinesis AgentのようなエージェントソフトウェアなどのPublisherを経由して、Amazon S3へと定期的に生データを投入します。

必要があれば、RDBやNoSQLなどのデータソースからも分析に必要となるデータを収集します。その後、ETLサービスのAWS Glueを活用してデータを統合・整理し、Amazon S3のデータをクエリで取得できるAmazon Athenaを用いて分析結果を取得します。

このアーキテクチャではPublisherからAmazon S3へのデータ送信を一定期間ごとに行いますが、ニアリアルタイムでデータをアップロードしたいケースもあるはずです。その場合は、以下にご紹介するプランA#2のように、データストリーミングサービスを用いることをおすすめします。

AWSには、ストリーミングデータをAmazon S3やAmazon RedShiftなどのデータストアに配信するAmazon Kinesis Data Firehoseというサービスがあります。ニアリアルタイム性が必要な場合はぜひ活用してください。次にプランBについてご説明します。

プランAのような構成は利便性が高いものの、AWS GlueやAmazon Athenaを用いないシンプルなアーキテクチャにしたい方もいらっしゃるでしょう。そこでプランBでは、データウェアハウスサービスのAmazon Redshiftにデータを格納します。Amazon Redshiftは現状ではインスタンス管理コストがある程度かかるものの、データ分析に用いる利点は非常に大きいです。

Amazon Redshiftへのデータの格納方法としてはプランAと同様に、書き込み元のクライアントが定期的にデータを送信する案や、Amazon Kinesis Data Firehoseを経由してストリーミング処理でデータ送信するなどの案が考えられます。

さらにお伝えしたいこととして、取材時点（2022年2月）ではまだプレビュー版なのですが、Amazon Redshiftにサーバーレスのモードが登場しています。この機能を利用することで、サービスのキャパシティ管理などが不要になり、運用コストが下がります。

加えて、Amazon Redshiftのストリーミング取り込みという機能が登場しています。こちらはプレビュー版です。Amazon Kinesis Data Firehoseを経由してAmazon Redshiftへデータを書き込むには数分ほどかかるのですが、ストリーミング取り込みの機能を用いれば、Amazon Kinesis Data Streamsからより即時的にAmazon Redshiftでデータが利用可能になります。

── 仮に「ダッシュボードに表示されるデータの更新頻度を下げて構わないので、なるべくシステム運用費用を安価に抑えたい」という場合には、どのような方法を用いるとよいでしょうか？

半場　分析を行ううえで必要な量や種類のデータを揃えなければならないのは、どのような手段を選んだとしても同じです。そのため、データ収集の設計・実装そのものをシンプルにメンテナンスしやすくしておくことが、運用コストを安価に抑えるポイントになります。たとえば、多くの方が慣れ親しんでいるバッチ処理でデータパイプラインを編成するような方法は、運用の工数を下げられますし、TCO¹を抑えるための定石になるはずです。

── また逆に「システム運用費用はある程度かかってもよいので、最新データをリアルタイムでダッシュボードに反映させたい」という場合はどうでしょうか？

半場　収集すべきデータが発生した際にすぐに処理する必要があるならば、ストリーム処理を用います。バッチ処理ではなくストリーム処理を用いると、出力先のデータストアに求められる処理特性も変わり得ます。たとえば、粒度の細かいデータを高い頻度で読み書きできるデータストアが必要になるはずです。

ただし、読み書き性能の高いデータストアにすべてのデータを保管すると、多くの場合はコストも高くなります。かつ、そうした特性のデータストアにデータを保管し続ける必要があるケースというのは、実際は少ないはずです。そのため、大抵の場合はデータストアのTieringが求められるようになります。

また、ストリーム処理の障害耐性を高めるには、Check-pointingやSnapshot取得がかなり重要になってきますが、これには大きな運用コストが必要になってくるはずです。そのため、データのすべてをストリーム処理にするのではなく、リアルタイム性がそれほど求められない箇所に関してはバッチ処理を用いるほうがよいでしょう。

パターン(2)：社内用途ではなく、サービス利用者に対して分析情報のダッシュボード機能を提供したい

── 分析情報のダッシュボード機能をサービス利用者に対して提供する場合、社内用途の場合とで、システム設計において考慮すべき点に差異は生じますか？

半場　分析基盤そのもののシステム構成は、基本的に大きく変わらないと思います。ただ、追加で考慮すべきことは何点かあります。まずはセキュリティです。サービスを利用するユーザーごとにアクセス制御をかけるために、認証・認可の仕組みを提供する必要が生じます。

また、サービスの成長に比例してユーザーも増えるため、スケーラビリティを考慮することも重要です。大量アクセスがあっても耐えることができ、かつアクセスが少ないときは無駄なコンピューティングリソースを使わないような伸縮性が重要になります。また、社内向けのツールならばユーザーインターフェースをそれほど気にする必要はありませんが、ユーザーに提供する機能ならば既存サービスとのUXの統一性も求められます。

これらの要件を実現するために有効なのが、Amazon QuickSightというBIツールです。Amazon QuickSightで生成したダッシュボードを、既存のアプリケーションの画面の中に組み込むことが可能です。

Amazon QuickSightで提供するダッシュボードはスタイルシートの調整も可能ですので、ユーザーに提供しているサービスの外観と親和性の高いユーザーインターフェースを提供できます。

こうしたBIツールをユーザーに提供する場合には、各種データへのアクセス可否をユーザーアカウントごとに制御できる権限設定機能もセットで実装してください。AWS Lake Formationを利用してデータレイクに蓄積されたデータへのアクセス制御をよりきめ細やかに制御する方法や、QuickSightに取り込んだデータソースへのアクセス制御を設定する方法などがあります。

権限設定はホワイトリスト方式にし、セキュリティが堅牢になるようにしましょう。そして同様にセキュリティの観点から、各ユーザーに永続的な権限を付与するのではなく、セッションベースなどで一時的な権限を付与する方式にします。

パターン(3)：BtoB SaaSなどにおけるテナント設計

── 次は内田さんに、BtoB SaaSなどにおけるテナント設計の手法を伺います。SaaSサービスを設計するうえで、「どのような方法でテナントを扱うか」は重要なテーマであり、情報のニーズも高いです。アカウントやデータベース、その他各種の分離レベルなどにおいて、押さえておくべき基本的なテナント設計の考え方を教えてください。

内田　テナント設計には、シングルテナントモデルとマルチテナントモデル、その中間のハイブリッドモデルの3つの選択肢があります。シングルテナントモデルはリソースをテナントが専有するモデル、マルチテナントモデルはリソースをテナント間で共有するモデル、ハイブリッドモデルはリソースをテナント間で一部共有し一部専有するモデルです。

共有または専有対象のリソースの代表例としては、AWSアカウントやVPC、アプリケーション、Amazon EC2のインスタンス、論理的なデータベース、データベースのテーブル、物理的なデータベース（ここではAmazon RDSのインスタンスを指します）などがあります。各モデルのメリットとデメリットを整理していきましょう。まずシングルテナントモデルからお話しします。

シングルテナントモデルのメリット / デメリット

まずはメリットです。シングルテナントモデルでは、リソースをテナントごとに分離します。これにより、セキュリティ・キャパシティの面でリソースが他のテナントの影響を受けなくなります。いわゆるノイジーネイバー問題が少ないということです。仮にテナントごとにAWSアカウントを分けていれば、あるAWSアカウントでセキュリティ・クレデンシャルが漏洩するインシデントが起きても、他のAWSアカウントは影響を受けません。

また、テナントごとにリソースを用意できるため、そのテナントに合わせて適切なサイズのリソースを使用できます。そして、マルチテナントと比較するとリソースサイズそのものが小さくなるため、大規模リソース特有の問題も起こりにくいです。

次にデメリットもお話しします。テナントごとにリソースを用意するということは、管理対象もそれだけ増えるということです。仮に1,000種類のテナントごとにAmazon EC2インスタンスを用意するならば、冗長構成にすると最低でも2,000台を運用する必要があります。また、管理対象が増えることによって、1つひとつのリソースを最適化することが難しくなり、アイドルタイムが生まれやすくコストがかさむという問題もあります。

── コスト増大をなるべく避ける方法はありますか？

内田　シングルテナント寄りのモデルを採用する場合は、AWSのサーバーレス系サービスを活用することをおすすめします。たとえばAmazon Aurora Serverless v2（取材時点ではプレビューリリース）を活用すると、コンピュート費用がかかるのはサービスにアクセスがあったときだけのため、アイドル時間の無駄なコストを低減することが可能です。

マルチテナントモデルのメリット / デメリット

── 次はマルチテナントモデルについてお願いします。

内田　マルチテナントモデルのメリットは、リソースをテナント間で共有するためコスト最適化がしやすいことです。たとえばAmazon RDSのインスタンスをテナント間で共有する場合には、あるテナントからのアクセスがなくても他のテナントは利用していることも多いため、アイドル時間がそもそも発生しにくいです。

また、共有することでリソース数が少なく済むことから、オペレーションの工数を抑えられ、運用しやすい側面があります。たとえばAmazon RDSのインスタンスをテナント間で共有する場合、データベーススキーマ変更時のALTER TABLEの実行回数は1回で済みます。

デメリットとしては、リソースをテナント間で共有するためセキュリティやキャパシティの面で他のテナントの影響を受けるノイジーネイバー問題が発生することです。類似の問題として、最も負荷の高いテナントに合わせてリソースを用意する必要があるという課題があります。

つまり高負荷のテナントが利用していなくても高パフォーマンスのリソースを稼働しつづける時間帯が発生し得るため、コストが割高になります。また、リソースをテナント間で共有することによってSPOF（Single Point Of Failure：単一障害点）が生まれやすくなるなど、別の観点での運用の難しさが発生します。

ハイブリッドモデルのメリット / デメリット

── ハイブリッドモデルはいかがでしょうか？

内田　ハイブリッドモデルは、サービスの要件に合わせてシングルテナントモデルとマルチテナントモデルの“良いとこ取り”を狙ったようなモデルです。

たとえば、マルチテナントモデルではノイジーネイバー問題があるという話をしましたが、スロットリングという仕組みを導入することなどにより、マルチテナントモデルの中で仮想的なシングルテナントモデルを実現します。スロットリングというのは、各テナントが利用できるAPIコール数やストレージサイズを決めておき、それ以上の利用が発生した場合には利用を制限するものです。

これにより、管理対象が少ないというマルチテナントモデルのメリットと、ノイジーネイバー問題が少ないというシングルテナントモデルのメリットの両方を享受します。ただ、万能というわけではなく、ハイブリッドするパターンに応じてデメリットも生じます。自分たちの提供するサービスの特性から、どのメリットを享受して、どのデメリットを受け入れるかを決めることが、モデル選びの基本です。

パターン(4)：トラフィック量の大きいシステムのアーキテクチャで考慮すべきこと

── サービスが成長した後のことも伺いたいです。トラフィック量が大きくなったサービスでは、パフォーマンスの課題が生じる可能性が高くなります。対策を立てるためにアーキテクチャ構築で考慮すべきことや、利用を推奨するAWSのサービスはあるでしょうか？

内田　何をもって“大規模”とするかは定義が難しいです。ある日突然トラフィックが増大する場合と徐々にトラフィックが増大する場合とでは、対応策が異なります。今回のインタビューでは、大規模トラフィックに耐えるためというよりも、「日々変化するトラフィックサイズに対応できるアーキテクチャにするには」という観点で考えてみます。

まず、垂直スケールではなく水平スケールしやすいアーキテクチャにしておくことが重要です。垂直スケールとは、より大きなサイズのリソースに載せ替えることでスケールさせる手法です。一方の水平スケールは、台数を増やすことによってスケールさせる手法です。

垂直スケールはリソースサイズの上限に応じてハードリミットが決まってしまいます。さらに、大きなサイズのリソースは運用時の取り回しにおいて融通が利きづらいため、基本的には避けたほうがよいでしょう。

── 水平スケールしやすくするために、やっておくべきことはあるでしょうか？

内田　システムをなるべく疎結合なアーキテクチャにしておくとよいです。だからといって全てをマイクロサービスにしようというわけではなく、基本的にはモノリスで構いません。将来的または現時点で負荷特性が全く違う部分を、別のシステムで処理するなどして、部分的にマイクロサービス化します。例えばApplication Load Balancerのpath based routingを利用すると、特定パスへのリクエストを別のシステムに振り分けることができます。

また、水平スケールのためにはステートレスな設計が望ましいです。たとえば、永続化が必要なデータをAmazon EC2のインスタンス上に保持することなどは、あまり良くありません。そのインスタンスを停止するのが難しくなったり、新しいインスタンスの追加が難しくなったりします。永続化が必要なデータはデータベースやストレージに置きます。

疎結合化や水平スケールを手助けするサービスとしては、Amazon API GatewayやApplication Load Balancer、Amazon SQS、Amazon SNS、AWS Auto Scaling、Amazon EventBridgeなどが挙げられます。同様にステートレス化を手助けするサービスとしては、Amazon RDSやAmazon S3、AWS Systems Manager Parameter Storeなどがあります。

AWS活用ノウハウ(1)：事業成長を見据えたAWSアカウントの管理方法

── さて、ここからはアーキテクチャにとどまらず、AWSを上手に活用するノウハウに関してお聞きします。AWSアカウントを上手に管理する方法について伺いたいです。

内海　ひとつのアカウントで多くの環境や機能、組織を収容しようとすると、規模が大きくなるにつれて運用に無理が生じます。そのため、私たちは企業規模に関わらず、すべてのお客さまが安全かつ迅速な開発に取り組めるように、最初からマルチアカウント構成でAWSをご利用いただくことをおすすめしています。

── 複数のAWSアカウントでシステムの開発・運用を行う際には、どのような基準でアカウントを分けるとよいですか？

内海　AWSアカウントはAWSリソースの管理単位であると同時に、セキュリティやガバナンス、請求の境界であることを理解しておくとよいです。

AWSアカウントの分割方法にはいくつかの代表的なパターンがあります。まずはデプロイメント環境による分割です。本番環境・検証環境・開発環境ごとにアカウントを分割することで、環境に応じたアクセスコントロールがシンプルに実装できます。特定の環境のみ、強いコスト制限を適用するような運用も可能です。

次に部門による分割です。部門ごとにアカウントを分割することで、コストの配賦先を明確にしたり、特定部門に特別なセキュリティポリシーを適用したりできます。プロダクトや機能によるアカウント分割も同じ効果があります。

さらに、AWSサービスの利用者やデータの機密度などのワークロードに応じて細かくアカウントを分割すると、規制対応のための監査やセルフアセスメントなどの範囲を限定できます。これら複数の観点に基づいてアカウントを分割します。

── アカウントを分けることによって生じる課題として、管理の煩雑さが挙げられます。その課題を解決するために便利なサービスはありますか？

内海　AWS Control Towerを利用することで、AWSのベストプラクティスに沿ったマルチアカウント環境を簡単に構築できます。AWS Control TowerはAWS OrganizationsやAWS Single Sign-On、AWS Service Catalog、AWS CloudFormation、AWS Config、AWS CloudTrailなどのサービスと連携します。

これにより、複数アカウントの一元管理や複数アカウントへのシングルサインオン、新規アカウントのプロビジョニング、アカウントの構成変更の監視、アカウントを操作した証跡の保存ができる環境をセットアップします。

AWS Control Towerがセットアップするマルチアカウント環境はランディングゾーンと呼ばれており、ログアーカイブ用アカウントや監査用アカウントなど、最初から分割して構成しておくべき共有アカウント群が自動的に作成されます。

また、禁止されている変更を予防するなどリスクの高い設定を検出するためのガードレールとして、AWS OrganizationsサービスコントロールポリシーやAWS Configルールも同時に作成されます。これらを各デプロイメント環境や部門、プロダクト、ワークロードのガバナンス要件に合わせて取捨選択することで、効率的にアカウントを管理できます。

AWS Control Towerでセットアップしたランディングゾーンに既存のAWSアカウントを参加させたり、シングルサインオン機能を社内・外部のIDプロバイダーと連携させたりといったカスタマイズも可能です。また、AWS Control Towerのランディングゾーンで管理する複数のアカウントにセキュリティのベースラインを設定する、BLEA（Baseline Environment on AWS）というソリューションもあります。

AWS活用ノウハウ(2)：コスト管理のベストプラクティス

── AWSにおける適切なコスト管理の方法も教えていただけますか？

内海　AWSではユーザーが起動・使用したリソースに対してのみコストが発生するため、アイドル状態のリソースを停止・削除する、稼働率の低いリソースをダウンサイジングする、ユースケースに応じたプライシングモデルを選択するなどの対応で費用対効果を最適化できます。

AWSの利用料金で注意すべき点は、意図せずリソースが大量に起動・使用された場合に、コストショックと呼ばれる想定外の費用が発生する可能性があることです。AWSの費用対効果を向上させるためだけではなくコストショックを素早く検出し対処するためにも、私たちはユーザーの方々にコストとリソースの使用状況を定常的に監視していただくようお願いしています。

また、コスト監視・分析のツールを用いるだけではなく、コストショックへの対応やコスト最適化方法の検討・適用という作業そのものを、開発プロセスの一部として組み込んでおくことも重要です。こうした施策を継続的に実施することが、コスト管理成功の秘訣と言えます。

── 定常的なコストの分析・改善はどのような方法で行うとよいですか？

内海　まずは、AWSマネジメントコンソールからAWS Cost Explorerを有効化しましょう。AWS Cost Explorer上では最大過去12か月分のコストと使用量のデータがグラフとして可視化されます。そのため、コストの傾向や要因、異常などを詳細に分析できます。過去の使用量に基づいて将来的な費用を予測することも可能です。

コストの改善方法はさまざまです。最初に取り組んでほしいのは、使用していないリソースの削除・停止です。AWS Trusted Advisorでコスト最適化チェックを実行すると、使用率の低いリソースを特定できます。表示された推奨事項に合わせて対象のリソースを削除・停止しましょう。他には、開発環境のAmazon EC2インスタンスを作業終了時に停止したり、土日祝日にAmazon Redshiftクラスターを停止したりするような運用も効果的です。

次に、使用しているリソースのサイズを適正化します。AWS Cost Explorerでリソース最適化の推奨事項を見ると、オーバープロビジョニングされたAmazon EC2インスタンスを特定できます。他にはAWS Compute Optimizerを用いることで、Amazon EC2インスタンスに加えてAuto ScalingグループやAmazon EBSボリューム、AWS Lambdaファンクションに関するリソース最適化の推奨事項も確認できます。

そして、使用するリソースを無駄のないタイプ・サイズに変更しましょう。その後は、Amazon S3のストレージクラスやAmazon DynamoDBのキャパシティモードなど、利用しているサービスの設定を見直します。

最後に、一定のリソース使用量を事前にコミットすることでコストを下げる方法を検討します。たとえばAWSが用意しているSavings Plansでは、1年または3年の期間で特定のリソース使用量を契約する代わりに、Amazon EC2やAWS Fargate、AWS Lambda、Amazon SageMakerをオンデマンド料金よりも圧倒的に安価で利用できます。

同様にリザーブドインスタンスでは、Amazon RDSやAmazon ElastiCache、Amazon DynamoDB、Amazon Redshift、Amazon OpenSearch Serviceなどのサービスで大幅な料金の割引を受けられます。先ほど述べたAWS Cost Explorerを利用すると、Savings Plansやリザーブドインスタンスのコスト削減効果を確認できます。

想定外の費用が発生したことをすぐに知るための方法としては、AWS使用料金をモニタリングして使用制限を超過しそうな場合に通知してくれるAWS Budgetsや、機械学習によって異常なコスト消費とその原因を特定するAWS Cost Anomaly Detectionをぜひ活用してください。

── みなさんに解説していただいた知見は、AWSを用いたアーキテクチャ構築に相当に役立ちそうです。どうもありがとうございました！

取材・執筆：中薗昴
撮影：野中崇史