はじめに

こんにちは！システム開発担当の林です！

今回はオンラインセキュリティ学習プラットフォーム(以下、セキュリティPF)を支えるAWSのインフラ構成について解説します。

また先日、大学で実施した弊社講師による模擬講義内でも、約80名の学生にセキュリティPFを利用して学習をしていただきました。そのときの運用状況も併せて紹介します。

セキュリティPFを支える各インフラについて

以下は(かなり簡略化した)このプラットフォーム全体の構成図です。

それぞれの構成要素を順に解説します。

ハンズオン環境

セキュリティPFは執筆時で100を超えるハンズオン学習コンテンツを提供しており、それぞれの学習コンテンツごとにサーバ構成やOS、NW、埋め込まれている脆弱性などが異なるハンズオン環境をユーザ専用環境として提供しています。

ハンズオン環境は主に以下の要素で構成されています。

踏み台サーバ
攻撃用サーバ
攻撃対象サーバ

また、それぞれのハンズオン環境ごとにサブネットやセキュリティグループも異なり、ラテラルムーブメントを実施するような学習コンテンツでは攻撃対象サーバも複数台構築されます。

今回の大学での模擬授業では、2つの学習コンテンツを扱いました。したがって、学生80名 * サーバ3台 * 2コンテンツの480台のサーバを講義内に構築したことになります。一般的なWebサービスから見れば同時接続数80人は非常に小さい数値だと感じると思いますが、このハンズオン環境を安定提供するというユースケースにおいてはそれでも非常に大きい数値であることが分かるかと思います。

このように短いライフサイクルで大量のサーバの構築・破棄を繰り返す必要があり、かつ、講義やイベント時には数十〜数百人が同時に構築するので、それを並列で処理することが求められます。

我々はこの要件を達成するためAWS CloudFormationを導入することにしました。CloudFormationはAWS専用のIaCツールで、スタックと呼ばれる単位で複数のAWSリソースをまとめて管理することができます。元々はEC2上でTerraformをホストして実行していましたが、Terraformは実行リソースを大量に必要とすることに加え、構築速度を少しでも早くすること・並列で構築すること、ハンズオン環境の破棄に失敗したときに中途半端にゴミが残らないこと、などの要件を踏まえCloudFormationが最適と判断しました。

ユーザごとハンズオン環境ごとに画像のように1スタックが作成されます。一目で作成中や作成完了・失敗が分かるので我々のユースケースのようにライフサイクルの短いリソースが大量にある場合には非常に便利です。また、スタックごとにトレースが見れるので、どの処理がボトルネックになっているのかも分かるため、構築速度向上に役立っています。

デプロイ基盤

ハンズオン環境を迅速にデプロイするためには、全ハンズオン環境で共通して利用するVPC、サブネット、ルートテーブル、NAT Gateway、Lambda等を事前に作成する必要があります。こちらもリソース間の依存関係が複雑、かつ、リソースも大量に存在するため、CloudFormationでスタックとして管理しています。

また、この基盤自体も、ハンズオン環境ほどではないですが、頻繁に作成・破棄を繰り返すものです。Terraformで管理していたころは稀にリソース間の依存解決に失敗して削除できなくなることがありましたが、AWSに特化したCloudFormationでは失敗頻度がかなり減りました。また、構築時間についても(厳密にはTerraform時代と構成が少し変わっているので単純な比較はできませんが)15分から7分程度と約半分になりました。

簡単に作成削除でき、トラブルシューティングも容易なため、新規着任者やインターン生でも環境構築等で詰まる時間が大幅に減ったという副次的な効果もありました。

アプリケーション/その他のリソース

ハンズオン環境やデプロイ基盤のような頻繁に作成削除を行うリソース以外の、以下のような比較的ライフサイクルが長いAWSのリソースはTerraform Cloudで構築しています。

AWS Cognito, CloudWatch, IAM, DynamoDB, RDS, ECR, ECS等

また、セキュリティPFの以下の主なアプリケーションはここで作成されるAWS ECS/Fargate上で実行されています。

フロントエンド (Typescript/Next.js)
Backend API (Python/Django)
- 認証、ユーザ・チーム管理、学習コンテンツ、学習履歴、スキル分析等のセキュリティPFの主機能を担う
インフラAPI (Python/Fast API)
- 前述の学習コンテンツごとに異なるハンズオン環境を構築するためのCloudFormationテンプレートの動的生成とAWSへのリクエスト等を担う

スケーリング戦略

我々の構成において、同時利用者数が増えたときに何がボトルネックになるかを考えます。

まず、ハンズオン環境を構築するCloudFormationですが、こちらはSaaSであるためAWSが定めるクォータの範囲内であればスケールを気にする必要がありません。また、ハンズオン環境のセットアップを行うAnsibleもLambdaで実行しているためスケールを気にする必要はありません。(AnsibleをLambdaを実行する点に関しては当社エンジニアのこちらのブログに詳しく書かれているのでぜひ併せてご一読ください。)

デプロイ基盤もRDS/DynamoDBといったPaaSを中心に構成されており、こちらもあまりスケールを気にする必要はありません。

次にアプリケーションですが、我々のアプリケーションは全てECS上で実行されており、スケールアップやスケールアウトが容易に可能です。また、講義やイベントなどは日勤帯に行われることが主であり、日程やカリキュラムなども概ね事前に把握することが可能です。そのため、手動およびスケジュールによる事前のスケールアップ・アウトができ、コスト最適なリソースを配置することが可能です。

メトリクスを監視してオートスケールすることも可能ですが、講義では生徒の足並みを揃えるため講師の指示でほぼ同時に操作を開始するため、ある種スパイクと同等であり、オートスケールでは間に合わないこともあるため、あくまでオートスケールは補助的な役割を果たします。

以下は講義中のECSのメトリクスです。講義の開始(14:40頃)とともにCPU・メモリともに上昇し、ハンズオン環境の構築指示が出たタイミング(14:45頃と15:20頃)でも急激に上がるのが分かります。今回は事前にスケール済みなのでそれでもとても快適に利用できていました。