AWS設計における設計書作成の進め方
クラウド環境の構築において、AWS（Amazon Web Services）はその柔軟性と豊富なサービス群で多くの企業に選ばれています。ただ、AWSを活用する上では適切な設計書を作成する方法を理解しておくことも重要です。
この記事では、AWS設計における設計書作成の進め方について、詳しく解説します。
AWS設計における要件定義書に必要な要素
AWS設計の第一歩として、重要なのは要件定義書の作成です。ここでは、要件定義書に含めるべき構成要素について、解説します。必要な要素を以下に示します。
基本構成
AWS環境の基本構成を明確にすることは、設計の基盤です。基本構成として記述すべきものには、以下のようなものが含まれます。
- システムの概要
- システムの構成図
- サービスパラメータ
- セキュリティ対策
基本構成では、まずどのようなシステムを構築するのかを明らかにしておきます。明確にこれを設計するということを定義しておくことで、以降の内容理解を手助けしてくれるでしょう。
システムの構成図は、システムを構成する各要素を図に落とし込みます。それぞれの要素の役割を視覚的に理解しやすくなるので重要です。
サービスのパラメータは、最も大きなボリュームゾーンとなる項目です。AWSで動かしている各種サービスのパラメータについて、細かく記載していきます。ここにはVPCの設計やサブネット構成などが含まれます。
セキュリティの有無、あるいはどのような対策を施しているかについても、忘れずに記載しましょう。システムを十分に守れる環境にあるかどうかを、ここで判断しましょう。
運用の概要
運用の概要とは、システムの実装に際してそれをどのように扱うかを説明したものです。
例えばシステム稼働後、それが正しい役割を果たすためにはどのような操作を実行しなければならないのか、そもそもそれの実行は手動なのか、自動なのかを記載します。定期的に操作が必要な場合は、どのタイミングで、どんな処理を実行するのかも示すことが重要です。
アラートの通知などイベントがあった際の手順についても、対応プロセスを明確にしておきましょう。仮に他の担当者に連絡する工程を挟む必要がある場合には、その際の緊急連絡先についても記載しておきます。
監視設定
監視はAWS運用の中核を担う存在です。監視設定を定義する際には、以下のような要素を決定することが求められます。
- Amazon CloudWatchのメトリクスとアラーム
- AWS Configによるリソースコンプライアンス監視
- セキュリティ監視（AWS Security HubやGuardDutyの活用）
たとえば、CloudWatch Alarmsを設定してCPU使用率やディスク使用率が一定値を超えた際に通知を受け取るようにすれば、確認漏れを減らし、迅速な対応が可能になります。また、AWS Configを活用してリソースの変更履歴を記録し、コンプライアンス違反を即座に検出する仕組みを構築することも重要です。さらに、GuardDutyで疑わしい活動を監視し、Security Hubでリスクを統合的に分析することで、セキュリティの強化を図ることができます。
AWSにおける設計原則
AWSはシステムの設計において有用性の高い基本原則を、公式に紹介しています。ここではAWSの設計原則について、簡単に整理しておきます。
ビジネス成果を中心にチームを編成する
設計するAWSのシステムは、組織のビジネス目標と一致している必要があります。チーム編成の際には、目標達成に必要なスキルと役割を明確化します。たとえば、開発チームと運用チームが緊密に連携するDevOpsのアプローチを採用し、ビジネスニーズに迅速に対応できるよう促す方法です。
またビジネス成果を重視した設計チームを構築できれば、プロジェクトの優先順位を明確にし、リソースを効率的に割り当てることができます。これにより、AWSリソースの選定やアーキテクチャ設計が目標達成に直結する形で進められるでしょう。
オブザーバビリティを実装して実用的なインサイトを得る
システムの動作状況を可視化し、リアルタイムでインサイトを得ることで、オブザーバビリティを確保しましょう。例えばCloudWatch Logs Insightsのようなサービスは、アプリケーションのエラー発生箇所やリクエストの処理時間を特定するクエリを作成できます。これによりトラブルシューティングの効率を高めることが可能です。
オブザーバビリティの向上はシステムの予期せぬ挙動を事前に把握し、障害が発生する前に対策を講じることが可能になる点も魅力です。
可能な場合は安全に自動化する
AWSでは、可能な限り自動化を活用することで、運用効率を高め、ヒューマンエラーを削減することを推奨しています。
たとえば、AWS Systems Managerを使用してパッチ適用やインスタンス管理を自動化したり、CloudFormationを活用してインフラのコード化を実現したりすることが挙げられます。自動化を行う際には、セキュリティを考慮したアクセス制御やロール管理が不可欠です。
小規模かつ可逆的な変更を頻繁に行う
AWSを使って構築したシステムは、大規模な変更よりも、小規模で段階的な変更を繰り返す方が、リスクを抑える上で効果的です。テクノロジーの進歩に伴い、今後はアップデートや再編の機会は増えていくことが予想されます。
これには、Gitなどのバージョン管理ツールやAWS CodePipelineを使用した継続的デリバリー（CI/CD）パイプラインの導入が役立ちます。可逆的な変更設計により、迅速に元の状態に戻すことができ、運用の安定性が向上します。
オペレーション手順を頻繁に改善する
運用の効率を向上させるには、定期的にプロセスを見直し、改善点を明確化することが重要です。
運用レビューを定期的に実施し、ドキュメント化された手順を必要に応じて更新することで、運用ミスを減らし、プロジェクト全体の透明性を高めることができます。業務が複雑化したり、属人化するリスクも回避可能です。
障害を予測する
AWSでは、設計段階であらかじめ障害を想定し、それに備えることが重要です。たとえば、カオスエンジニアリングの手法を活用して、意図的に障害を発生させるような手法は一定の効果が期待できます。システムの復元力をテストし、実際に同様のインシデントが発生した場合に迅速な対応が可能です。
このような取り組みを通じて、予期せぬトラブルが発生しても迅速に対応できる体制を構築できます。
運用上のイベントとメトリクスから学ぶ
運用中に発生するイベントや収集したメトリクスを分析することで、運用フローを最適化できます。CloudWatch Logs InsightsやAmazon QuickSightの活用は、データを視覚化して重要なインサイトを得ることができる、大切な工程です。
マネージドサービスを使用する
AWSが提供するマネージドサービスを活用することで、インフラ運用の負担を軽減できます。Amazon RDSやAmazon DynamoDBはその代表格で、データベース管理の複雑さを軽減し、開発者がアプリケーションに集中できる環境を提供します。
AWSが紹介している主な設計パターン
AWSの設計書を作成する場合、目的に応じたフォーマットを活用することで、品質を高めることができます。ここではAWSが公式に公開している、主な設計パターンについて解説します。
腐敗防止層パターン
腐敗防止層パターンは、新しいシステムと既存のレガシーシステムを統合する際に、レガシーシステムの複雑さや制約が新システムに影響を与えないようにするための手法です。
このパターンを適用することで、異なるシステム間のデータや機能のやり取りを調整し、新システムの健全性を保つことができます。
APIルーティングパターン
APIルーティングパターンは、異なるクライアントからのリクエストを適切なサービスやエンドポイントに振り分ける手法です。
このパターンを採用することで、複数のサービスが統一されたAPIゲートウェイを通じて提供され、システムの拡張性と保守性が向上します。
サーキットブレーカーパターン
サーキットブレーカーパターンは、システム内の障害が他の部分に波及するのを防ぐための手法です。特定のサービスやコンポーネントが過負荷や障害状態にある場合、その部分へのリクエストを一時的に遮断し、システム全体の安定性を維持することができます。
Amazon API GatewayやAWS App Meshといったサービスを使用することで、サービス間の通信を制御し、障害発生時の影響を最小限に抑えることが可能です。
イベントソーシングパターン
イベントソーシングパターンは、システムの状態をイベントの履歴として記録する方法です。データの整合性や変更履歴の追跡が重要な場合に有効なこのパターンは、すべてのデータ操作がイベントとして保存されるため、システムの現在の状態を容易に再構築できます。
イベントソーシングパターンに役立つ主なサービスには、Amazon EventBridgeやAmazon SQS、DynamoDB Streamsなどが挙げられます。
六角形アーキテクチャ
六角形アーキテクチャパターンは、別名「ポートとアダプターパターン」とも呼ばれるパターンです。
アプリケーションのビジネスロジックと、インフラストラクチャコードを分離することを目的としています。このパターンを用いることで、外部サービスやユーザーインターフェースに依存せず、アプリケーションコンポーネントを個別にテストできる疎結合な構造を実現可能です。データベースやユーザーインターフェースの技術的な変更に際し、ビジネスロジックに与える影響を最小限に抑えることができます。
散布図パターン
散布図パターンは、タスクを複数の並列プロセスに分散し、その結果を集約する手法です。
これにより、処理の並列化を達成し、全体の処理時間を短縮することができます。散布図パターンは、業務上で大量のデータ処理や複雑な計算を必要とするシステムにおいて、非常に有効です。
バックオフ再試行パターン
バックオフ再試行パターンは、サービス間の通信においてエラーが発生した際、一定時間待機して再試行することでリソース消費を抑える設計手法です。このパターンは、過負荷状態や一時的な障害によるエラーが想定される環境で特に有効です。
過負荷によるシステムのダウンを回避する際などにおいて、高い効果を発揮します。
Sagaパターン
Sagaパターンは、分散システムにおけるトランザクション管理のための設計手法です。このパターンでは、各ステップを独立したトランザクションとして処理し、ステップ間で整合性を保つことができます。
シナリオによっては、失敗時に補償トランザクションを実行してロールバックする仕組みを組み込みます。
Strangler Figパターン
Strangler Figパターンは、レガシーシステムを段階的に新しいシステムへ移行するための設計手法です。
レガシーシステムの特定部分を置き換え、新しいシステムに統合しながら、既存の機能を維持します。この手法は、既存システムを一度にリプレースするリスクを軽減するのに適しています。
トランザクションアウトボックスパターン
トランザクションアウトボックスパターンは、分散システムでデータ整合性を維持するための設計手法です。
このパターンでは、ローカルトランザクションで「アウトボックステーブル」にイベントを記録し、その後、非同期でイベントを配信します。この方法により、メッセージ送信とデータベース操作の一貫性を確保します。
クラウド設計書作成の手順
AWSの設計書作成においては、各工程を順序立てて実施することが重要です。以下の手順に則ることで、効率的な設計書作成を進められるでしょう。
目的と要件の明確化
クラウド導入の第一歩は、組織のビジネス目標を明確にすることです。目標が明確になることで、クラウドソリューションが組織の戦略と整合し、最大の価値を引き出すことができます。
続いて、ビジネス目標に基づき必要なクラウド機能を洗い出します。データストレージやコンピューティングリソース、ネットワーキング、データベースサービスなど、課題解決につながる機能を剪定しましょう。
クラウド環境におけるセキュリティ、可用性、スケーラビリティの要件も定義します。これらの要件は、システムの信頼性と将来の拡張性に直結するため、重要なプロセスです。
設計パターンの選定
上で紹介した、AWSのクラウド設計パターンを活用し、システム要件に最適なパターンを選定します。
どのような課題を解決したいのかによって、選ぶべきパターンは変わってくるものです。設計パターンのそれぞれの特徴についての理解を深め、ベストな選択を目指しましょう。
アーキテクチャ設計
選定した設計パターンに基づき、システム全体のアーキテクチャを設計します。アーキテクチャ設計には、各コンポーネントの配置、データフロー、サービス間のインターフェースなどを含みます。設計内容に漏れがないよう、確認を怠らないことが大切です。
実装手順の計画
アーキテクチャの設計ができたら、システムの実装手順を計画しましょう。各工程で発生する業務の確認や、配分するリソース、担当者の配置などを、この段階で決定します。
運用とモニタリングの計画
設計段階から、システム稼働後の運用・モニタリング計画にも目を向けておきます。システムは稼働させて後の維持管理にも、大きな負担が発生するものです。
障害の発生などのインシデントリスクを最小限に抑えられるよう、パフォーマンス監視、障害対応、定期的なメンテナンス、セキュリティアップデートなどを怠らない仕組みづくりに徹しましょう。
設計書の文書化
これまでの全てのステップを詳細に文書化し、設計書としてまとめます。明確で包括的な設計書は、チーム内の共有や将来のメンテナンスにおいて重要な役割を果たします。具体性の高い設計書を作成することで、業務の属人化の回避や、引き継ぎ業務の簡素化などにつながるのがメリットです。
ベストプラクティスの確認
最後に、AWSのベストプラクティスと照らし合わせ、設計内容を確認および修正します。AWSは運用や設計についてのベストプラクティスを広く共有しており、これに則ることで、システムの最適化とリスクの最小化が図れるでしょう。
まとめ：基本に忠実なAWS設計を実現しよう
この記事では、AWS設計において知っておきたい基本の設計原則や、主なクラウド設計のパターン、そして設計業務の進め方について、解説しました。
AWSは一般的な業務の多くに適用可能な設計パターンを公開しており、これに則って設計を進めることで、質の高いAWS運用を実現可能です。
AWSの設計に際しては過度な独自性が求められることはないため、ひとまず基本に忠実に設計プロセスを踏むことをおすすめします。
この記事をシェア
