雲の呼吸 壱ノ型~AWS設計の勘所：コスト編~

はじめに

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

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

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

第一回目は「コスト」です。

コストは設計の考慮事項でも最重要事項

今から遡ること2000年以上前、紀元前3世紀のギリシアにあったエピロス国のピュロス王は戦術の天才と呼ばれ、イタリア半島を統一しようとしていた古代ローマと戦い二度勝利を収めました。ただ自軍の損害も大きく、三度目の戦いでローマに敗れました。この故事から「割に合わない勝利」のことを「ピュロスの勝利」と言ったりします。

営利企業であれ、非営利法人であれ、組織が事業を展開するにあたってコストの問題は常に付きまといます。どんなに優れた設計であっても、コストがかかってサービスの継続が難しくなってしまうとするなら本末転倒になります。ピュロスの勝利になってしまっては元も子もないわけです。

クラウドの利用が加速しているのは、コスト面でもメリットがあるからですが、漫然と利用していては、そのメリットを最大限に生かすことはできません。

コストを削減するための設計心得

では、コストを抑える設計のポイントはどういったものがあるでしょうか。私が思うに、以下のような点がポイントになるかと思います。

• Amazon EC2 Auto Scalingで必要な時に必要な分だけ起動する
• 安価なストレージを利用する
• 割引オプションを利用する
• 要求される可用性を見極める
• サーバレスを積極的に利用する

Auto Scalingで必要な時に必要な分だけ起動

クラウドを使うメリットの一つは仮想化されたCPUやメモリを自由に追加、削除できることです。代表例はAmazon EC2のAutoScaling設定です。Auto ScalingはAmazon CloudWatchの任意のメトリクス(例えばCPU使用率)の指標をもとに、EC2インスタンスの台数を増減させる機能です。

多くのワークロードにおいて、長期間に渡って常に一定のリソースが必要ということはあまりないでしょう。Webサービスであれば、利用者の増減がありバッチ処理であれば、データの増減があります。なので、Auto Scalingによって負荷の増減に対応して、EC2インスタンスの台数を増減させることは有力な基本方針の一つです。

基本と書いたのは、Auto Scalingはサーバの起動時間が数分かかるのでスパイクアクセスには有力な選択肢とならないことや、Auto Scalingを運用するには、サーバ自身には重要なデータを置かない（ステートレスにする）必要があるなど、注意点もあるからです。

安価なストレージを利用する

基本的にはAmazon S3にデータを保持するようにした方が良い場合が多いです。

S3

保存コストが安いということもありますが、耐久性もすぐれています。S3にデータを保存することで、EC2をステートレスにしてAuto Scalingの適用を可能にする利点もあります。

データの耐久性を少し落とした低冗長化ストレージのオプションも存在するので、ワークロードに合わせて、検討すると良いと思います。

ただし、ブロックストレージを代替するものではないので、読み書きを頻繁に行うファイルの保存先には向いてません。また、キャッシュなどの低いレイテンシを求められる用途にも向いてません。

Amazon S3 & Amazon S3 Glacier Deep Archive

S3よりさらに安価な保存携帯がGlacier、およびその派生のGlacier Deep Archiveです。

アクセス頻度が稀で、長期的に保存しておきたいデータの保存先として候補になります。例えばログデータであったり、監査用のデータなどです。

ただし安価である代わりに、取り出しに時間がかかります(標準で3〜5 時間、Deep Archiveであれば12時間以内）。

Amazon EBS

EC2やAmazon RDSにはEBSというブロックストレージを必ず使用します。アプリケーションでデータを保持する上で、一番シンプルに利用できるますし、レイテンシも低く利用できます。ですが、コスト観点で見ると必ずしも最適な選択肢とは言えません。また、複数のEC2サーバから読み書きするような用途には向きません。基本的にEBSには必要最小限のデータだけを持つのが良いでしょう。

Amazon EFS

NFSサーバのようにファイルを共有できるEFSというサービスがあります。単純なストレージコストとしてはEBSより高くなってしまいますが、複数のサーバからファイルを共有したい場合には候補となります。

どれを使えばいいの？

基本的にはデータの格納先としては

• S3を第一候補とする
• アクセスが稀であればGlacierおよびGlacier Deep Archiveを検討
• ファイルシステム上で共有したい場合はEFSを使用
• それ以外はEBS

という選択が良いでしょう。

割引オプションを利用する

AWSには、起動しているEC2などの料金を節約するためのオプションがいくつか存在します。

Amazon EC2 リザーブドインスタンス & Savings Plans

ある程度長期間サーバを起動することが見込まれる場合には、リザーブドインスタンスを検討すべきです。ある程度予測がきくワークロードであれば、最初から検討しても良いでしょうし、ある程度サービスを運用してみて、あたりが付いた時点で導入しても良いかと思います。

長期間利用することを約束する代わりに、割引を受けられるというのがリザーブドインスタンスのメリットではありますが、Availavility Zone(以下、AZ）を指定したリザーブドインスタンスは、インスタンスを起動する権利(キャパシティ)を確保することができるのもメリットの一つです。

というのも、通常の起動（オンデマンドインスタンス）や、後述するAmazon EC2 スポットインスタンスの場合、AWS上に対象の余剰リソースがない場合には起動できない可能性があります。そのため、確実に指定した台数のインスタンスを起動したい場合はキャパシティ予約を行う必要がありますが、AZのリザーブドインスタンスを購入すると同時にキャパシティの予約ができます。

※なお、キャパシティ予約はリザーブドインスタンスなしでも可能ですが、リザーブドインスタンスと組み合わせたほうが安くなります。

リザーブドインスタンスに加えて、最近追加されたオプションがSavings Plans です。リザーブドインスタンスは、インスタンスサイズやリージョンやAZなどを指定して割引を受けますが、Savings Plansはその制限がなくコンピュータ処理能力に対する課金額を対象とするので、
EC2だけでなく、AWS FargateやAWS Lambdaにも適用できるなど、より柔軟な割引を受けることができます。

スポットインスタンス

AWS上の余剰リソースを格安で利用できるオプションがスポットインスタンスです。

利用期間や利用額を前提とすることなく、通常よりもかなり安くインスタンスを利用できるオプションですが、注意点があります。

まず、余剰リソースを利用できるオプションなので、対象のインスタンスタイプに空きリソースがない状態では起動することができません。

加えて、サーバが勝手に停止されてしまう可能性があります。そのため、途中で停止してしまっても、リカバリが可能なワークロードでのみ使用するほうが良いでしょう。例えば、Amazon EMRに代表される分散処理基盤上のタスクノードとしての利用は最も適した利用法です。Hadoopのような分散処理基盤のフレームワークには、ノード故障などに対してリカバリーをする仕組みが備わっているので、意図しないタイミングでいくつかのノードが停止されても処理をリカバリーすることができるようにデザインされています。

また、停止される場合に、通知を受けられるので、通知を受けたらELBから切り離すなどの仕組みを作ることで、APIのバックエンドサーバとしても利用することも可能です。

ただし、全てをスポットインスタンスのみでアーキテクチャを組んでしまうと、余剰リソースがない時にすべての処理が停止してしまうことになってしまうので、最低限欲しいリソースについてはリザーブドインスタンスを組み合わせて利用するなどしたほうが賢明です。

要求される可用性を見極める

PoC(概念実証)用の環境など、高い可用性を要求されないケースはあると思いますが、本番用の環境であっても可用性を多少犠牲にして、コストを抑えることも戦略の一つとしては考えられます。

例えば、大規模災害を想定して、BCP（事業継続計画）のためのDR(ディザスタリカバリ)として、
別リージョンにデータなどを配置することはよく行われますが、その際にも、いくつかの戦略が考えられます。

• 別リージョンに同様の可用性をもった環境を起動しておき、常に冗長構成(Active/Active)で稼働させるマルチサイト
• 別リージョンに最低限稼働する環境を起動しておき、障害が発生したタイミングで切り替えるウォームスタンバイ
• 別リージョンにデータベースのレプリカを起動しておき、障害時に他の環境を構築してサービスを継続させるパイロットライト
• 別リージョンにデータベースのスナップショットを定期的に送っておき、障害時に他の環境を構築してサービスを継続させるバックアップ/リストア

などです。

上から順番に可用性は低下しますが、かかるコストは低くなっていきます。

ただし、
ベストプラクティスとしてはサーバなどのリソースを冗長化させることで可用性を確保するのが推奨されます。「障害の可能性が低いから大丈夫だろう」という希望的観測で可用性を犠牲にするのはやめたほうが良いでしょう。「発生する可能性があるものは将来必ず発生する」という前提のもと、対処策を考えた上で、可用性とコストを天秤にかけるべきです。

サーバレスを積極的に利用する

クラウドならではのコスト削減策の極意はサーバレスです。

AWSに限らず、クラウドベンダーは従量課金をメリットにあげていますが、EC2/RDSなどのサーバを起動している場合、サーバを起動しておくだけで処理を行っていなくても料金がかかってしまいます。もちろん、それを100パーセント常に使っているのであれば良いでしょうが、常時余分にリソースを確保するケースが大半でしょう。サーバレスなサービスを利用することで、その余分なコストを最適化できます。

サーバレスの明確な定義は難しいですが、特徴としては、

• 実行基盤としてのインフラ管理を意識しない（サーバがないわけではなくサーバを意識しない）
• 使用料に応じた柔軟な課金体系

が挙げられると思います。

その典型がLambdaです。Lambdaはイベントドリブンな関数実行サービスなので、実行に応じて課金されます。なので、リソースを余分に確保するためのコストを削減できます。

Amazon API Gatewayを利用すれば、RESTなAPIのバックエンド処理としても実行できます。EC2をAPIのバックエンド処理として利用する際には、冗長性を考慮するとELBも基本セットになりますが、
API GatewayとLambdaとを利用して構築することで、EC2のコストだけでなく、Elastic Load Balancing(ELB)のコストも削減することができます。

Lambdaと組み合わせて使うのに最適なサーバレスなNoSQLデータベースがAmazon DynamoDBです。DynamoDBは、RDSやAmazon ElastiCacheと違って、インスタンスという概念がありません。キャパシティユニットという性能を決めるための設定値とデータの保存量に応じて課金されます。キャパシティユニットやテーブルのキー構成などをワークロードに合わせて適切に検討すれば、コストメリットを享受できます。

また、オンデマンドキャパシティという事前にキャパシティユニットを指定する必要がないオプションやリザーブドキャパシティという最低限の使用量を約束する代わりに安くなる割引サービスもあるので、合わせて検討すればよりコストメリットを高めることができます。

もちろん、なんでもかんでもサーバレスがいいかというと、決してそうではありません。

Lmabdaは実行時間などいくつかの制約もあるので、ワークロードでLambdaの利用が適切かよく検討する必要があります。DynamoDBもRDBMSや他のNoSQLを代替するものではないので、用途の向き不向きがあります。

とはいえ、基本的な考え方としては、
「サーバレスな構成にできないか」をまずは検討することで、コストの削減をできる可能性は高いと思います。

最後に

以上、AWS上でコストを考慮した設計を行う際の勘所でした。もちろん、この他にもAWSにはコストを削減するための便利なサービスや設定がたくさんあります。それらを有効に活用することで、多くのコストメリットを得られることでしょう。

連載第二回はこちら：雲の呼吸 弐ノ型~AWS設計の勘所：マネージドサービス・前編~

浅田さんのご紹介： AppiritsのAI研究者が『2020 APN AWS Top Engineers』に選出！資格取得に対する取り組みを紹介！