クラウド技術は開発や運用の点において非常に大きな恩恵がある一方でその構築と管理には重要な課題があります。コンソール上で手動設定する従来の方法ではスケーラビリティや再現性の問題が生じやすく、大規模な環境ではその複雑さが増してしまいます。

こうした課題を解決するために、DigeonではAWS Cloud Development Kit（AWS CDK）を用いて、インフラストラクチャをコードとして管理するアプローチを取り入れています。

ここでは、Digeonで採用しているCDKの構成例とそれぞれの役割を紹介していきます。

AWS CDKとは

AWS CDKは、TypeScriptやPython、Javaなどの一般的なプログラミング言語を使用して、AWSのリソースを定義・プロビジョニングできるツールです。

リソースをプログラムとして持つことで、インフラ構成をGitベースで管理でき、バージョン管理や自動化が容易になります。

Digeonではある程度共通する構成をテンプレートコードとして管理しています、これによって基本的なWebアプリケーションについてはインフラの初期設定にかかる時間を大幅に短縮し、即座に稼働可能な環境を構築できます。

また、特定の要件に合わせてこのテンプレートをチューニングすることで、共通の基盤を維持しつつ各プロジェクトの固有のニーズにも対応できます。

プロジェクトごとに異なる条件や設定値はプログラムコードとしてではなく、`cdk.json`というCDKのプロパティ設定ファイルで管理するようにしています。API・データベースのスペックやバッチ処理のスケジュールだけでなく、ログの保存期間のような細かな設定も含めるようにしており簡単に設定を変更できます。

# cdk.jsonの例

"rds": {
  "instanceClass": "burstable3",
  "instanceSize": "medium",
  "port": 3306,
  "defaultDatabaseName": "sample",
  "backupRetentionDays": 2,
  "autoScaling": {
    "minCapacity": 0,
    "maxCapacity": 10,
    "targetUtilizationPercent": 60
  },
  "isAuroraEnabled": true
},

CDKの全体構成

Digeonでは、CDKテンプレートとして以下の構成を持つインフラ環境を構築しています。

バックエンド

バックエンドは以下の構成で構築されています。

ECSではコンテナ化されたアプリケーションをFargateモードによるサーバレス環境で動作させています。これらはタスク定義によってそれぞれを最適なスペックで動作するように、プロジェクトごとにチューニングできます。

APIはALBを介してトラフィック分散され、マルチAZによる冗長化とオートスケーリングの設定による可用性を持たせています。外部からAPIにアクセスする際は、マルチAZで動くそれぞれのタスクにこのALBを通じて振り分けられます。

フロントエンド

フロントエンドは以下の構成で構築されています。

CDKからCloudFront Functionもデプロイでき、状況に応じてBasic認証をかけたりメンテナンスページへリダイレクトさせることができます。

システム監視

バックエンド・フロントエンド共通でリアルタイムでのシステムの監視と通知機能を持たせています。

CloudWatch Logsを用いてログとメトリクスを監視し、cdk.jsonで設定したしきい値を超えたものをSNS(Simple Notification Service)とChatbotを経由してSlackへ送信できます。

cdk.json上でシステム監視の有無を切り替えることができ、本番環境をデプロイする段階でステージング環境の監視をoffにし、本番環境をonにするというような操作が簡単に行えます。

さいごに

今回はDigeonが管理しているCDKテンプレートの構成の一部を紹介しました。このテンプレートを素にプロジェクトに応じたインフラ構成を作成していますが、同時にテンプレート自体にも機能を取り入れてさらなる汎用化を進めています。

今後はさらに実装ベースに踏み入った内容も発信していこうと考えております。AWSの導入を考えられている方やCDKの実装方針について困っている方がいらっしゃれば参考になれば幸いです。