【試行錯誤】AWSのシステム構成図の作り方の流れについて考える

AWS

プロジェクトの要件定義工程において、システム構成図を作成することがありました。
ある程度現場の方針により、運用や管理面から使うアーキテクチャについては制限がありましたが、改めて業務要件にあったシステム構成はどのようなものがよいのかを検討する機会がありましたので、その内容を書いていきます。
色々検討すべきポイントはあり、ここで記載する内容には漏れが多くあるかと思いますが、今回自身で考えた点を中心に記載していきます。

AWSシステム構成図の作成の流れ

以下の流れでシステム構成図の検討を実施しました。

  1. 非機能要件の検討
  2. 業務要件、機能要件の確認
    • 業務要件を検討するチームの方で業務要件や機能要件の整理および要件定義を作成していると想定しています。
    • 要件定義の中で、以下のようなシステム構成に影響のある情報を確認します。
      • プロジェクトで構築対象となるシステムと接続するユーザやシステム
      • システムで取り扱うデータ
      • 処理方式(オンラインやバッチ処理、想定するインタフェースなど)

  3. AWSサービスの選定
    • フロントエンド、バックエンド、バッチ処理、データベース、セキュリティ周りの検討をします。
    • フロントエンドは、静的コンテンツ及び動的な部分の実装を検討します。
      • 静的コンテンツの利用サービス例:S3やCloudFront
      • 動的部分の利用サービス例:Lambda, EC2, ECS など
    • バックエンドは、コンテナ化するのであればECS、サーバレスであれば、API Gateway+Lambda などのサービスを非機能要件で検討した想定業務量をもとに選定します。
    • データベースは、業務のデータの特性やアクセスパターンをもとに、リレーショナルデータベースやNoSQLを選定します。今回はRDBでもNoSQLでもいけそうでしたが、プロジェクトの標準化に合わせてRDBを選定しました。この辺りは勉強不足感があるので、もう少し勉強して別の記事で書ければと思います。
    • セキュリティは、非機能要件で整理したセキュリティの要件や会社・業界のガイドラインに従い実装を検討していきます。ガイドラインによってはサードパーティーのセキュリティ製品を使う場合もあるかもしれませんので、その場合はAWSのみで完結できないので面倒ですね…。

  4. システム構成図に落とし込む
    • これまでに整理した利用AWSサービスや、業務の機能ごとの通信の流れをもとにシステム構成図を書いていきます。
    • AWSのアイコンは以下公式から提供されているアイコンを利用し、例によってExcelなどに張り付けていきます。フォーマットがあるプロジェクトであれば、それに合わせてシステム構成図を書いていきます。
      ※AWS アーキテクチャアイコン:https://aws.amazon.com/jp/architecture/icons/

まとめ

今回は以下のようにシステム構成図を整理していきましたが、プロジェクトにより必要なタスクが変わってくるかと思います。自身の頭の整理も兼ねて書いてみましたが、また経験を積んでブラッシュアップしていきたいと思います。参考になれば幸いです。

  1. 非機能要件の検討
  2. 業務要件、機能要件の確認
  3. AWSサービスの選定
  4. システム構成図に落とし込む

コメント

タイトルとURLをコピーしました