誰

• kotamat
• SCOUTER ROXX CTO
• サーバー、インフラ寄り
•  🚴‍♂️

だけkotamats

転職にまつわるサービスを展開

エージェント

転職者

求人企業

なぜインフラに設計が必要なのか

時代はオンプレからクラウドへ

• 一つのインスタンスにすべてを突っ込む時代
• ↓
• IaaSが提供しているマネージドのサービスを結合する時代へ

構成管理もクラウドベースへ

• インスタンスのプロビジョニングを行うChef, Ansible
• ↓
• マネージドの構成を管理するTerraform, CloudFormation
  • サーバーサイドはサーバーサイド言語のみが動く環境へ
  • k8sなどのコンテナ技術によりプロセスベースで分割する時代へ

クラウドを考慮した設計が必要

• モジュール管理
• サービス間連携
• セキュリティー
• 守りつつ攻めるインフラ

アプリ設計とインフラ設計

似てるところ

"役割"と"結合"

役割

結合

TCP/IP :443

TCP/IP :80

bucket policy

結合

TCP/IP :443

TCP/IP :80

bucket policy

役割

依存性方向の存在

モジュール間で明確な依存関係

• AutoScaling←ScalingPolicy
• Storage←Storage AccessPolicy
• LoadBalancer←Listener

概念で分ける

アプリ

すべてをコントローラーには書かず、ドメインロジック等を分けて記述する。

インフラ

一つのマネージドサービスに関わる全ての設定を一つのモジュールにするのではなく、アプリケーションの概念ごとにモジュールを切り分ける

ex) CloudFront自体はグローバルのモジュールへ、CloudFrontのOriginは各アプリケーションのモジュールへ

アプリ設計とインフラ設計

似てないところ

結合部もモジュールの一つ

• FireWall(security group, S3OriginIdentity等)
• モジュール内に内包することもあるが、FW自体をモジュール化しても構わない。
• 概念として含めるべきか、別で管理したほうがいいかを都度判断

大抵1レイヤーに1モジュール

• 一つのアプリで一つのモジュールをたくさん使うことはない
  • ex.) デプロイのマネージドは本番デプロイとステージングだけ等。
• 故にほとんどがレイヤー同列のモジュールとして構成される。
• プラグインを多用するような設計に近い。

ステージングと本番

• インフラ構成用のステージング環境を用意する
• 本番とは競合しないものを構築。
• "何を共有構成"とし、"何を環境依存にするか"は明確化する
  • コンポネントの命名にプレフィックスを付ける(stg-, prod-)
  • ステージングと本番のプロキシサーバー
  • インスタンス、コンテナの容量や数(トラフィックや料金的なもの)