自分はどうやってインフラ設計してるんだろう？🤔

インフラ設計するの好き。システム構成描くの好き。自分はそんなエンジニアもどき。インフラとの出会いはオンプレから始まって、今はAWS一択でやっている。今後もオンプレに戻る予定はない。

「インフラの構成図はよく描くけど、そういうば自分はどう設計してるんだろう」とか思ったこのごろ。あんまり説明できない。なんかインフラの設計は空から降りてくるものだと思っている（ﾏﾃ）。

割と↑がガチなのだけれども、あえて設計の価値観に順位付けすると↓の通りだと思う。

1. コンピュートリソースがLambdaであること

2. シンプルであること

3. AWSのベストプラクティスに沿っていること。大きくずれてないこと

4. その他（セキュリティとかバックアップとか冗長性とか、、、）

こんな感じ。いつも無意識に描いてるので、漏れがあるかも。だけど、そんなに間違ってないと思う。ちなみに自分はLambda原理主義者。ECSとかLambdaが絶対できない場合でないと使わない（ちなみにそんなシチュエーションはないと思っている。つまりいつもLambda）。

つぎにリソースを決め方を考える。決める順番は↓の通り。

1. データベース

2. ネットワーク周り

3. バックエンド周り

4. フロントエンド周り

5. バッチ処理周り

かな？私はシステムってDBを操作するためのIFだと思っている。だからシステム≒DBだと思っている。一番大切なところから決めていくのが歪みなく設計できると思っていて、そうなると必然的にDB選定から始まる。DBのアクセスパターンを考えてRDSなのかDynamoなのかを考える（グラフDBとか気になるけど使ったことない。いつか使ってみたい）。自分は最初にだいたいDynamoが使えないか考える。要件的に合致しなかったり、シンプルな構成にならなかったりするならRDSを検討する。バックエンドとフロントはチームの技術スタックでほぼ決まると思っている。バッチ処理は曲者でLambdaのタイムアウト15分制限で終わらない見込みだったり、そもそもLambda １つで完結しないことが多くてケースバイケースのピタゴラ装置になりがち。

次に実際にインフラ設計する流れはこんな感じ

1. 自分向けにオレオレユースケース図（UC図）を描く

2. アクターを洗い出す

3. 外部APIやAWS（アカウント単位くらいの粒度）とアクターの関係を矢印で繋ぐ

4. 各AWSのアカウントの中のインフラを設計する

こんな感じだと思う。自分的にUC図が大切。これは絶対に描いてる。ほぼ確実に最初はUC図から着手する。少なくとも初期要件の９割くらいは網羅するレベルで描いてる。逆にこれが描けないなら要件の理解が甘いと思っている。要件全部がインフラに乗るわけだから、設計者は要件の全貌を自分の言葉で把握してなきゃだめだと思ってる（設計したあとは忘れる）。またUC図を描くとアクターの見落としを防げるもの大切だと思う。アクターはユーザーだったり、管理者だったり、あるいはBotちゃんだったりする。全部のアクターがわかるだけで、システム全体のイメージがだいぶつかめる。こんな感じでUC図を描いてるとインフラのイメージがどんどんついてくる。そして一番最初に戻るんだけど、UC図を描いているとインフラ設計が頭の中へ降りてくる。後は降りてきた設計をガリガリ描き残して完了する。

ちなみに私はインフラが降りてきたら、その後はUC図を更新しない。完全に描き捨て。自分のために描いている。だから自分がわかるオレオレUC図で良い。自分の納得する粒度でいい。粒度だってそろってなくていい。そう思ってる。

だいたいこんな感じにインフラ設計してるんじゃないかなーという気持ち。

みんなは何考えて設計してるんだろー🤔