ケーススタディ：製品にAWSクラウドインフラストラクチャを使用する理由

公開: 2022-03-11

AWSは、複雑で要求の厳しいソフトウェア製品を実行するためのプラットフォームとして、必要なときに必要な規模でリソースを利用することで柔軟性を提供します。オンデマンドで瞬時に実行できるため、実行環境を完全に制御できます。このようなクラウドアーキテクチャソリューションをクライアントに提案する場合、プロビジョニングされるインフラストラクチャとその価格は、事前に設定する必要のある要件に大きく依存します。

この記事では、LEVELS向けに提案および実装されたそのようなAWSクラウドインフラストラクチャアーキテクチャの1つを紹介します。これは、ユーザーが使用しているカードプログラム、所有しているもの、または配置するカードプログラムで得られる可能性のあるすべてのメリットを見つけて適用する、統合された顔の支払い機能を備えたソーシャルネットワークです。彼らが住んでいます。

要件

クライアントには、提案されたソリューションが満たさなければならない2つの主要な要件がありました。

安全
スケーラビリティ

セキュリティ要件は、ユーザーのデータを外部からの不正アクセスから保護することだけでなく、内部からも保護することでした。 スケーラビリティの要件は、製品の成長をサポートし、トラフィックの増加と時折発生するスパイクに自動的に適応し、サーバーに障害が発生した場合の自動フェイルオーバーとリカバリを実行して、潜在的なダウンタイムを最小限に抑えるインフラストラクチャの機能に関するものでした。

AWSセキュリティコンセプトの概要

独自のAWSクラウドインフラストラクチャをセットアップする主な利点の1つは、完全なネットワーク分離とクラウドの完全な制御です。これが、確かなセキュリティのデフォルトを提供するが、完全できめ細かい制御ができない、やや単純なPlatform as a Service（PaaS）環境を実行するのではなく、Infrastructure as a Service（IaaS）ルートを選択する主な理由です。 AWSを使用して独自のクラウドをセットアップします。

LEVELSはAWSコンサルティングサービスのためにToptalにアプローチしたときは若い製品でしたが、ユーザーデータとプライバシーを非常に懸念しているため、AWSに積極的に取り組み、インフラストラクチャで最先端のセキュリティが必要であることを認識していました。その上、彼らは将来クレジットカード処理をサポートすることを計画しているので、彼らはある時点でPCI-DSSコンプライアンスを確保する必要があることを知っていました。

仮想プライベートクラウド（VPC）

AWSのセキュリティは、独自のAmazon Virtual Private Cloud （VPC）の作成から始まります。これは、AWSリソースをホストし、AWSクラウド内の他の仮想ネットワークから論理的に分離された専用の仮想ネットワークです。 VPCは、独自のIPアドレス範囲、完全に構成可能なサブネット、ルーティングテーブル、ネットワークアクセス制御リスト、およびセキュリティグループ（事実上、ファイアウォール）を取得します。

LEVELSでは、本番環境を開発、テスト、およびQA環境から分離することから始めました。最初のアイデアは、それぞれを完全に分離された独自のVPCとして実行し、それぞれがアプリケーションの必要に応じてすべてのサービスを実行することでした。検討の結果、3つの非本番環境間でリソースを共有できるようになり、コストがある程度削減されたことがわかりました。

したがって、本番環境を1つのVPCとして、開発、テスト、およびQA環境を別のVPCとして決定しました。

VPCレベルでのアクセス分離

2つのVPCセットアップは、ネットワークレベルで残りの3つの環境から本番環境を分離し、偶発的なアプリケーションの設定ミスがその境界を越えないようにします。非実稼働環境構成がデータベースやメッセージキューなどの実稼働環境リソースを誤って指している場合でも、それらにアクセスする方法はありません。

同じVPCを共有する開発、テスト、およびQA環境では、構成が間違っている場合に境界を越えたアクセスが可能ですが、これらの環境はテストデータを使用するため、分離されていないため、実際のセキュリティ上の懸念はありません。

アセットストアのセキュリティモデル

アセットはAmazonSimpleStorage Service（S3）オブジェクトストレージに保存されます。 S3ストレージインフラストラクチャはVPCから完全に独立しており、そのセキュリティモデルは異なります。ストレージは、環境やアセットのクラスごとに個別のS3バケットに編成され、適切なアクセス権で各バケットを保護します。

LEVELSを使用すると、ユーザーアップロード、LEVELSで作成されたコンテンツ（プロモーションビデオおよび同様のコンテンツ）、WebアプリケーションとUIアセット（JSコード、アイコン、フォント）、アプリケーションとインフラストラクチャの構成、サーバー側の展開バンドルなど、いくつかのクラスのアセットが識別されました。

これらのそれぞれは、個別のS3バケットを取得します。

アプリケーションシークレット管理

AWSには、暗号化されたAWSSystemsManagerパラメーターストアまたはAWSSecretsManagerがあります。これらは、シークレットを安全に保つように設計されたマネージドキーバリューサービスです（詳細については、Linux Academyおよび1Strategyをご覧ください）。

AWSは、基盤となる暗号化キーを管理し、暗号化/復号化を処理します。シークレット自体は、インフラストラクチャとユーザー（それぞれサーバーと開発者）の両方に対して、キープレフィックスに基づいて適用される読み取りおよび書き込み権限ポリシーを持つことができます。

サーバーSSHアクセス

完全に自動化された不変の環境にあるサーバーへのSSHアクセスは、まったく必要ありません。ログを抽出して専用のログサービスに送信できます。また、監視は専用の監視サービスにオフロードされます。それでも、構成の検査とデバッグのために、たまにSSHアクセスが必要になる場合があります。

サーバーの攻撃対象領域を制限するために、SSHポートはパブリックネットワークに公開されません。サーバーには、外部SSHアクセスを可能にする専用マシンである要塞ホストを介して到達し、ファイアウォールで許可されたIPアドレス範囲のみをホワイトリストに登録することでさらに保護されます。アクセスは、ユーザーの公開SSHキーを適切なボックスに配置することによって制御されます（パスワードログインは無効になっています）。このような設定は、悪意のある攻撃者が通過するためのかなり回復力のあるゲートを提供します。

データベースアクセス

上で概説したのと同じ原則がデータベースサーバーに適用されます。また、データベース内のデータに直接接続して操作する必要がある場合もありますが、これは絶対に推奨される方法ではなく、サーバーのSSHアクセスを保護するのと同じ方法でそのようなアクセスを保護する必要があります。

SSHトンネリングで同じ要塞ホストインフラストラクチャを利用して、同様のアプローチを使用できます。 1つは要塞ホストへの二重SSHトンネルが必要であり、もう1つはデータベースにアクセスできるサーバーへのトンネルです（要塞ホストにはデータベースサーバーアクセスがありません）。その2番目のトンネルを介して、ユーザーのクライアントマシンからデータベースサーバーへの接続が利用可能になります。

AWSスケーラビリティの概念の概要

純粋にサーバーについて話すとき、スケーラビリティはAWSよりも単純なプラットフォームでかなり簡単に達成されます。主な欠点は、特定の要件をプラットフォームの外部サービスでカバーする必要がある場合があることです。つまり、データがパブリックネットワークを通過し、セキュリティの境界を超えます。 AWSを使い続けると、すべてのデータがプライベートに保たれますが、スケーラブルで復元力があり、フォールトトレラントなインフラストラクチャを実現するには、スケーラビリティを設計する必要があります。

AWSの場合、スケーラビリティへの最善のアプローチは、プラットフォームを使用する数千のクライアント間でバトルテストされたモニタリングと自動化を備えたマネージドAWSサービスを活用することです。データのバックアップとリカバリのメカニズムを組み合わせて追加すると、プラットフォーム自体に依存するだけで、多くの懸念が解消されます。

これらすべてをオフロードすることで、運用チームの規模を縮小し、プラットフォームマネージドサービスのコストの上昇をいくらか相殺することができます。 LEVELSチームは、可能な限りその道を選んで喜んでいました。

Amazon Elastic Compute Cloud（EC2）

EC2インスタンスを実行する実証済みの環境に依存することは、実行中のコンテナーの追加のオーバーヘッドと複雑さ、またはサーバーレスコンピューティングのまだ非常に若くて急速に変化するアーキテクチャーの概念と比較して、依然としてかなり合理的なアプローチです。

EC2インスタンスのプロビジョニングは完全に自動化する必要があります。自動化は、さまざまなクラスのサーバー用のカスタムAMIと、現在のトラフィックに応じてフリート内の実行中のサーバーインスタンスの適切な数を維持することにより、動的サーバーフリートの実行を処理する自動スケーリンググループによって実現されます。

さらに、自動スケーリング機能を使用すると、実行するEC2インスタンスの数の下限と上限を設定できます。下限はフォールトトレランスに役立ち、インスタンスに障害が発生した場合のダウンタイムを排除できる可能性があります。上限はコストを管理し、予期しない極端な状況が発生した場合にダウンタイムのリスクを許容します。次に、自動スケーリングにより、これらの制限内のインスタンスの数が動的にスケーリングされます。

Amazon Relational Database Service（RDS）

チームはすでにAmazonRDSfor MySQLで実行されていますが、適切なバックアップ、フォールトトレランス、およびセキュリティ戦略はまだ開発されていません。最初の反復では、データベースインスタンスが各VPCの2インスタンスクラスターにアップグレードされ、マスターおよびリードレプリカとして構成され、自動フェイルオーバーがサポートされました。

次のイテレーションでは、MySQLバージョン5.7エンジンが利用可能になり、インフラストラクチャはAmazonAuroraMySQLサービスにアップグレードされました。完全に管理されていますが、Auroraは自動的にスケーリングされるソリューションではありません。自動ストレージスケーリングを提供し、容量計画の問題を回避します。ただし、ソリューションアーキテクトは、コンピューティングインスタンスのサイズを選択する必要があります。

スケーリングによるダウンタイムは回避できませんが、自動修復機能を使用して最小限に抑えることができます。より優れたレプリケーション機能のおかげで、Auroraはシームレスなフェイルオーバー機能を提供します。スケーリングは、必要な計算能力を備えたリードレプリカを作成し、そのインスタンスへのフェイルオーバーを実行することによって実行されます。次に、他のすべてのリードレプリカもクラスターから取り出され、サイズが変更されて、クラスターに戻されます。手動でのジャグリングが必要ですが、実行可能以上のものです。

新しいAuroraServerlessオファリングは、コンピューティングリソースのある程度の自動スケーリングも可能にします。これは、将来的に検討する価値のある機能です。

マネージドAWSサービス

これらの2つのコンポーネントを除いて、システムの残りの部分は、フルマネージドAWSサービスの自動スケーリングメカニズムの恩恵を受けています。それらは、Elastic Load Balancing（ELB）、Amazon Simple Queue Service（SQS）、Amazon S3オブジェクトストレージ、AWS Lambda関数、Amazon Simple Notification Service（SNS）であり、アーキテクトによる特別なスケーリング作業は必要ありません。

可変インフラストラクチャと不変インフラストラクチャ

サーバーインフラストラクチャを処理するための2つのアプローチを認識しています。サーバーがインストールされ、継続的に更新および変更される可変インフラストラクチャです。また、プロビジョニング後にサーバーが変更されることのない不変のインフラストラクチャ。構成の変更やサーバーの更新は、共通のイメージまたはインストールスクリプトから新しいサーバーをプロビジョニングし、古いサーバーを置き換えることで処理されます。

LEVELSでは、インプレースアップグレード、構成変更、または管理アクションなしで不変のインフラストラクチャを実行することを選択できます。唯一の例外は、アプリケーションの展開です。これはインプレースで行われます。

可変インフラストラクチャと不変インフラストラクチャの詳細については、HashiCorpのブログをご覧ください。

アーキテクチャの概要

技術的には、LEVELSはモバイルアプリであり、REST APIバックエンドといくつかのバックグラウンドサービスを備えたWebアプリです。これは、今日ではかなり一般的なアプリケーションです。これに関して、次のインフラストラクチャが提案および構成されました。

仮想ネットワークの分離-AmazonVPC

この図は、VPC内の1つの環境の構造を視覚化したものです。他の環境も同じ構造に従います（アプリケーションロードバランサー（ALB）とAmazon AuroraクラスターがVPCの非本番環境間で共有されますが、ネットワーク設定はまったく同じです）。

VPCは、フォールトトレランスのためにAWSリージョン内の4つのアベイラビリティーゾーンにわたって構成されます。ネットワークアクセス制御リストを備えたサブネットとセキュリティグループにより、セキュリティとアクセス制御の要件を満たすことができます。

フォールトトレランスを追加するためにインフラストラクチャを複数のAWSリージョンにまたがるのは、ビジネスとその製品の初期段階では複雑すぎて不要でしたが、将来的にはオプションになります。

コンピューティング

LEVELSは、バックグラウンドで発生するアプリケーションロジックのバックグラウンドワーカーを使用して、従来のRESTAPIを実行します。これらは両方とも、AutoScalingGroupsによって完全に自動化されたプレーンEC2インスタンスの動的フリートとして実行されます。 Amazon SQSマネージドサービスは、バックグラウンドタスク（ジョブ）の分散に使用され、独自のMQサーバーを実行、保守、およびスケーリングする必要がありません。

画像処理など、アプリケーションの他の部分と共有されるビジネスロジックを持たないユーティリティタスクもいくつかあります。このようなタイプのタスクはAWSLambdaで非常にうまく実行されます。これは、 Lambdaが無限に水平方向にスケーラブルであり、サーバーワーカーと比較して比類のない並列処理を提供するためです。

負荷分散、自動スケーリング、およびフォールトトレランス

負荷分散はNginxまたはHAProxyを介して手動で実現できますが、 Amazon Elastic Load Balancing（ELB）を選択すると、負荷分散インフラストラクチャが本質的に自動的にスケーラブルで、可用性が高く、フォールトトレラントであるという利点が追加されます。

ELBのApplicationLoadBalancer（ALB）フレーバーが使用され、ロードバランサーで利用可能なHTTPレイヤールーティングを利用します。フリートに追加された新しいインスタンスは、AWSプラットフォームのメカニズムを介してALBに自動的に登録されます。 ALBは、インスタンスの可用性も常に監視します。これには、異常なインスタンスの登録を解除して終了し、AutoScalingをトリガーして新しいインスタンスに置き換える機能があります。この2つの相互作用により、EC2フリートの自動修復が実現されます。

アプリケーションデータストア

アプリケーションデータストアはAmazonAuroraMySQLクラスターであり、マスターインスタンスと多数のリードレプリカインスタンスで構成されています。マスターインスタンスに障害が発生した場合、リードレプリカの1つが自動的に新しいマスターインスタンスに昇格します。このように構成されているため、要求されたフォールトトレランス要件を満たします。

リードレプリカは、その名前が示すように、データ読み取り操作のためにデータベースクラスターの負荷を分散するために使用することもできます。

データベースストレージはAuroraを使用して10GB単位で自動的にスケーリングされ、バックアップもAWSによって完全に管理され、デフォルトでポイントインタイムリストアを提供します。必要に応じてデータベースのコンピューティング能力をスケールアップすることを除いて、データベース管理の負担を実質的にゼロに削減します。これは、心配することなく実行するために支払う価値のあるサービスです。

資産の保管と提供

LEVELSは、保存する必要のあるユーザーのアップロードされたコンテンツを受け入れます。 Amazon S3オブジェクトストレージは、予想通り、そのタスクを処理するサービスです。クライアントアプリで利用できるようにする必要があるアプリケーションアセット（UI要素-画像、アイコン、フォント）もあるため、S3にも保存されます。 S3は、内部ストレージレプリケーションを通じてアップロードされたデータの自動バックアップを提供し、デフォルトでデータの耐久性を提供します。

ユーザーがアップロードする画像はさまざまなサイズと重量であり、直接提供したり太りすぎたりするために不必要に大きくなることが多く、モバイル接続に負担をかけます。さまざまなサイズでいくつかのバリエーションを作成すると、ユースケースごとにさらに最適化されたコンテンツを提供できるようになります。 AWS Lambdaは、万が一の場合に備えて、アップロードされた画像のオリジナルのコピーを別のバックアップバケットに作成するだけでなく、そのタスクにも活用されます。

最後に、ブラウザーを実行するWebアプリケーションも静的アセットのセットです。継続的インテグレーションビルドインフラストラクチャはJavaScriptコードをコンパイルし、各ビルドもS3に保存します。

これらすべてのアセットがS3に安全に保存されると、S3がパブリックHTTPインターフェースを提供するため、直接、またはAmazonCloudFrontCDNを介して提供できます。 CloudFrontは、アセットを地理的に分散させ、エンドユーザーへのレイテンシーを削減し、静的アセットを提供するためのHTTPSサポートも有効にします。

インフラストラクチャのプロビジョニングと管理

AWSインフラストラクチャのプロビジョニングは、ネットワーキング、AWSが管理するリソースとサービス、およびベアEC2コンピューティングリソースの組み合わせです。マネージドAWSサービスは、まあ、管理されています。適切なセキュリティをプロビジョニングして適用する以外は、それらとはあまり関係がありませんが、EC2コンピューティングリソースでは、構成と自動化を自分で処理する必要があります。

ツーリング

ウェブベースのAWSコンソールを使用すると、「レゴブリックのような」AWSインフラストラクチャの管理は簡単ではなく、手作業と同様にエラーが発生しやすくなります。そのため、専用のツールを使用してその作業を自動化することが強く望まれています。

そのようなツールの1つは、 AWSによって開発および保守されているAWSCloudFormationです。もう1つは、HashiCorpのTerraformです。複数のプラットフォームプロバイダーを提供することで少し柔軟な選択肢になりますが、主にTerraformの不変のインフラストラクチャアプローチ哲学のためにここでは興味深いものです。 LEVELSインフラストラクチャの実行方法に合わせて、Terraformは、ベースAMIイメージを提供するためのPackerとともに、最適であることが判明しました。

インフラストラクチャのドキュメント

自動化ツールの追加の利点は、詳細なインフラストラクチャドキュメントが不要であり、遅かれ早かれ古くなることです。プロビジョニングツールの「InfrastructureasCode」（IaC）パラダイムは、ドキュメントとしてダブし、実際のインフラストラクチャを常に最新の状態に保つという利点があります。高レベルの概要があり、変更される可能性が低く、最終的な変更で比較的簡単に保守できるので、側面に文書化するだけで十分です。

最終的な考え

提案されているAWSクラウドインフラストラクチャは、将来の製品の成長にほぼ自動的に対応できるスケーラブルなソリューションです。ほぼ2年後、専任のシステム運用チームが24時間年中無休で常駐することなく、クラウドの自動化に依存して、運用コストを低く抑えることができました。

セキュリティに関しては、AWSクラウドはすべてのデータとすべてのリソースを同じクラウド内のプライベートネットワーク内に保持します。パブリックネットワークを移動するために機密データは必要ありません。外部アクセスには、信頼できるサポートシステム（CI / CD、外部監視、またはアラート）へのきめ細かいアクセス許可が付与され、システム全体での役割に必要なリソースのみにアクセス範囲が制限されます。

このようなシステムは、アーキテクチャとセットアップが正しく行われているため、柔軟性、回復力、安全性が高く、製品の成長に合わせたスケーリングやPCI-DSSコンプライアンスなどの高度なセキュリティの実装に関する将来のすべての要件に対応できます。

Herokuや同様のプラットフォームなどの製品化されたオファーよりも必ずしも安価であるとは限りません。これらのオファーがカバーする一般的な使用パターンに適合している限り、これらはうまく機能します。 AWSを選択することで、インフラストラクチャをより細かく制御できるようになり、提供されるAWSサービスの範囲に柔軟性が加わり、インフラストラクチャ全体の微調整機能を備えたカスタマイズされた構成が得られます。

アマゾンパートナーネットワーク（APN）の高度なコンサルティングパートナーとして、Toptalは企業にクラウドソリューションを提供し、企業の旅のあらゆる段階で協力しています。

Toptal Engineeringブログでさらに読む：

宿題をする：AWS認定ソリューションアーキテクト試験の7つのヒント
TerraformとCloudFormation：決定的なガイド
AWSSSMを使用したSSHロギングとセッション管理
TypeScriptとJestサポートの操作：AWSSAMチュートリアル