自分がアーキテクチャを考えるならどうするかの雑記
前置き
以下書いた内容をo3-mini-highに読んでもらって不足点・矛盾点を指摘してリライトしてもらったものを後半に記載してます。
まともな話はそっちに書いてあるので、そっちが気になる方は目次のChatGPT先生による指導という項目に飛んでください。
目的
色々な言説を見てたりこの頃業務している中で「次やるならこうだな」という理想論がなんとなく見えてきたので雑にメモし頭を整理すること。
この整理作業を通じて僕が学ぶべきことを明確にすること。
前提
httpリクエストを受けてレスポンス返すシステムしか開発経験がないのでそれが前提にある。
ハイトラフィック捌くシステムの裏の人ではない。
安く済むならそれが嬉しい。
バックエンドエンジニア（と名乗って良いのか自信ない）なのでそっちに思考が行きがち。
人命が関わる（車や飛行機、ロケットとか）システムは想定してない。
アーキテクチャ考える際にどうするか？
どうしたらシステムとして不合格か考える
不合格を出すのはユーザー。
自分がユーザーだったらそのシステムをいつ不合格と見做しそうか考えて、執行者とよく会話する。
そのビジネスが提供している「価値」を提供する場合の
- エラー率が高ければ高いほど
- エラーが出た際にリカバリしてくれないほど
不合格に近づく。（気がする）
最低合格点は
例えば映画館なら、最低合格点は「チケットを買って席を予約したら間違いなく当日映画が観れること」。
ECサイトなら最低合格点は「商品を買ったら確実に届くこと」。
（だけど今はECは群雄割拠状態なので最低合格点が引き上げられていると思うし、上だけだと足りないと思った。ちゃんと執行者と一緒に調査して自分も執行者として主体的に考える作業が必要かも。）
最低合格点を下回ると不合格となる。
多分、執行者と一緒に調査して考えるうちに「ああ。ここの検索体験が良いのは当たり前だな。」とか色々わかってくるかもしれないので、そこで「ここのページ表示は常にX秒」とか色々一緒に決めていく。
リクエストの予測を立てる
多分プロダクトが満たすべき品質の解像度が上がったはずなので、そこを満たすためにバックエンドエンジニアとしてどうすべきか考える。
（フロントエンドは経験がないのでわからないけど、そこは専門家がいないなら利用ツールがボトルネックを生み出す箇所を特定する作業を地道にやっていくしかない気がする。）
プロダクトが満たすべき品質の解像度が上がったはずなので、どれくらいのリクエスト数が来るのか予測を立てる。
既存システムなら
- ユーザー数*1日の活動におけるアクションによる理論上の想定数
- ユーザーごとのアクションログを集計
してその差分を参考にしつつユーザーのアクションモデルを作ってみるとか？
それともユーザーが施策により爆増することを想定してするのか？など。
大体は売上高を構成する要素に依存する気がする。
アーキテクチャを考える
ここまだ微妙なんだよな・・・。
詰まるところ、google sre books 第12章のように論理的に考えられるようになりたいだけなんだよな・・・。
あまり慣れてない道具使う時は？
ドキュメント読んだら、小さく組み込んでconfig変えて負荷かけまくってみて特性を把握する。
相談できるならする
aws使ってても使ったことないサービスだと負荷がかかった時どうなるか予測がつかない。日頃から技術コミュニティに顔出しておいて詳しい人を見つけておいてちゃんと仲良くなって会話させてもらえるようにするとかもありな気がする。（できてない。）
負荷をかけて各種リソースのメトリクスを計測してプロダクト品質を担保できてそうかチェックする
プロダクト品質を満たすためのリクエスト数をベースに負荷をかける。
クラウドサービス使ってるなら、各種リソースのメトリクスで何をみるべきか決めておいてよく観察する。
試験結果が悪くてもクラウドサービスの場合、ボトルネックがどこなのかみてconfig変えたりコードを書き換えたりとか頑張る。
アーキテクチャ選定自体がミスってる場合に合うほど経験がないので、その場合自分だったらめっちゃ執行者に謝った上でリリースまでに必要な最低限のことを考えてリリース日伸ばしてもらったり、リリースしてから基準を満たすようにタスク分解して後からやるとか考える。
ここをミスりたくないので「アーキテクチャを考える」段階で慎重になるべきなのか・・・・？予算があるなら複数の案を走らせるとかした方が良いのか・・・・？
ChatGPT先生による指導
ユーザー視点に基づく品質基準の明確化
システムが「合格」か「不合格」かを判断するのは最終的にはユーザーです。ユーザーが求める「価値提供」が実現されているかを数値や具体的な指標で明確にする必要があります。
具体的な品質指標
- レスポンス時間: 例）常に○秒以内（例：2秒以内）
- エラー率: 例）全リクエストに対して0.1%未満のエラー
- リカバリ速度: 障害発生時に○分以内に復旧
基準設定プロセス
- 執行者（オペレーターやプロダクトオーナー）との共同調査
- ユーザー行動や既存の利用状況データに基づく定量的な評価
- 業界標準や競合分析を参考に最低合格点を設定
これにより、例えば映画館で「チケット購入後は必ず当日上映が保証される」やECサイトで「商品購入後は確実な配送」が実現されているか、客観的に評価できるようにします。
リクエスト予測とシナリオ分析
プロダクトが目指す品質を実現するため、どの程度のリクエスト数や負荷が発生するかを正確に予測することが重要です。
現状分析
既存システムのユーザー数、1日のアクション数、各ユーザーの行動ログなどから基礎的なリクエスト数を算出する。
過去のデータと理論値の差分を分析し、ユーザーの行動モデルを構築。
シナリオ設計
- ベースライン: 通常時のアクセスパターン
- ピーク時: プロモーションや特定施策での急増を想定
- 異常系: 想定外の急激なアクセス増加、障害発生時のリカバリシナリオ
- シミュレーション:各シナリオに対して負荷テストを実施し、リソース（CPU、メモリ、ネットワーク、DB）のボトルネックを特定。
その結果を元にアーキテクチャの設計や設定変更を検討。
アーキテクチャ設計のプロセス
アーキテクチャ設計は論理的な評価と、実際の検証を両輪とするプロセスです。
設計方針
ユーザーが求める品質（上記3.参照）を提供できる構成を論理的に検証する。
Google SRE Workbook 第12章などの理論を参考に、抽象度を落として具体的な実装計画に落とし込む。
意思決定プロセス
複数のアーキテクチャ案を「コスト」「パフォーマンス」「信頼性」「拡張性」などの観点で評価。
各案のメリット・デメリットを文書化し、ステークホルダーと議論して最適な選択を行う。
未経験技術へのアプローチ
新しいツールやサービスは、まず小規模なプロトタイプで実験。
ドキュメントを読み、実際に構成に組み込み負荷をかけることで特性を把握する。
技術コミュニティや内部の専門家と定期的に相談し、最新情報やノウハウを取り入れる。
負荷テストとリソースモニタリング
クラウドサービス利用時には、各種メトリクスを定義し、システムが期待通りの性能を発揮しているかを継続的にチェックすることが不可欠です。
負荷テスト
リクエスト数を基にシナリオ毎の負荷テストを実施し、各リソース（サーバ、DB、ネットワーク）の限界を測定。
テスト結果を元に設定やコードの最適化を図る。
モニタリング
CPU使用率、メモリ、ディスクI/O、レスポンス時間、エラー発生率などの主要指標をリアルタイムで監視。
異常を早期に発見するためのアラートシステムを構築。
技術的なリスクとリスクマネジメント
新しい技術や未経験のツールを利用する場合、予測不能なリスクが伴います。これを未然に防ぐための対策が重要です。
リスク分散
ペアプログラミングやコードレビュー、段階的なリリース・ロールアウトによるリスクの分散。
未経験サービスについては、事前のプロトタイピングと負荷テストで挙動を確認。
コミュニケーション
日頃から技術コミュニティや社内のエキスパートと連携を深め、疑問点を早期に解消する。
不測の事態が発生した場合、迅速に関係者に情報共有し、対応策を検討する。
セキュリティと障害リカバリ計画
ユーザー体験の質の向上だけでなく、セキュリティ対策や障害時のリカバリ戦略も必須項目です。以下の対策を検討することが望まれます。
セキュリティ対策
定期的な脆弱性診断とアップデート
アクセス制御、データ暗号化、監査ログの取得
リカバリ戦略
障害発生時のバックアップ体制とリカバリ手順の整備
冗長構成（フェイルオーバー、ロードバランシング）によるシステムの高可用性の確保
緊急時の連絡体制とインシデント対応計画の策定
まとめ
システムアーキテクチャの設計は、ユーザーが求める価値を数値化し、実際の利用シナリオをシミュレーションするプロセスから始まります。
具体的な品質基準の設定、リクエスト予測、シナリオ分析、実践的な負荷テスト、そしてセキュリティ・リカバリ戦略まで、各要素を体系的に検討することで、安定したシステム運用が可能になります。
また、未知の技術へのチャレンジはリスクも伴うため、コミュニケーションや段階的な検証を通してリスクを最小限に抑える工夫が必要です。
このフレームワークを基に、今後も継続的な学習と改善を重ね、より実践的で信頼性の高いシステム設計を目指していきます。
Discussion