インフラ設計のセオリー

theory.md

インフラ設計のセオリー

課題設定

次にインフラの設計を行うときに何を考慮すべきなのかを参考にする

可用性を考慮した設計

いかに単一障害点(SPOF)を排除するかを考える。
そのための対策が冗長化

ハードウェアの冗長化

• フォールトトレラント
• ロードバランシング
• リンクアグリゲーション

性能・拡張性を考慮した設計

• システムを使用するユーザーの数
• システムへ同時にアクセスするユーザーの数
• システムで扱うデータの量・保存期間
• レスポンスタイム目標値
• スループット目標値 システムの性能設計・サイジングの進め方

CPU、メモリ、ディスクの関係性

CPU = 頭脳
メモリ = 机の上
ディスク = 引き出し

ヒープ領域

アプリケーションで使用するメモリ領域のこと。 この領域を超えてしまうと、Out of Memoryが起きてしまう。

運用フェーズのシステム拡張

• システムのレスポンス悪化
• ディスク領域の不足
• 業務機能拡張による

システムのレスポンス悪化

- 利用ユーザーの急激な増加はないか
- CPUやメモリの使用率に問題はないか
　→CPUは90%がライン、メモリは何%？
- Webアプリケーションサーバのヒープサイズ使用率は問題ないか？ 
　[OutOfMemoryError の調べ方](https://qiita.com/opengl-8080/items/64152ee9965441f7667b)
- データベースのキャッシュヒット率は高いレベルで安定しているのか？ 
　[[Amazon Aurora]クエリキャッシュ検証：RDS for MySQLとの比較結果](http://scsk-db.jp/mysql/topics/2017/12/18-095106.html)
　[Amazon Aurora MySQL データベース設定のベストプラクティス](https://aws.amazon.com/jp/blogs/news/best-practices-for-amazon-aurora-mysql-database-configuration/)
- ネットワーク転送速度が問題になっていないか？
　ここはクラウドだとどこを確認すべきなのだろうか？
- アプリケーションサーバーやデータベースサーバーのディスクI/Oが問題になっていないか

ヒープ領域サイズに問題があるとすると、ヒープ領域の拡張を検討する。  
その際に注意すべきことが下記の点  
**OSのメモリサイズ + ヒープ領域 <  サーバーの物理メモリ量**  

もしこれが逆転しまうと、OSのページング機能が働くことになり、性能が大幅に低下することになってしまう。
ページング機能→物理ディスクをメモリの代用として使用する機能
[はりぼてosにページング機能を追加する](https://qiita.com/machine_engineer/items/cbb4fb5fe2b4402999ac)

仮想化

仮想化などの技術発展により(コンテナ技術)、上記のようなことを全て直接手で物理サーバーをいじくる必要がなくなりました。 今後も技術発展により、煩雑な作業はなくなっていくと思われる。

性能・拡張性を考慮した設計

最初に決めなければいけないのは、運用時間

システム停止時間

データのメンテナンス、セキュリティパッチの適応などの時に起こりうる。 セキュリティパッチ

実行する足は、「メンテナンスのお知らせ」を事前にページに反映させる必要がある。

バックアップ

何をどのように取得すべきか、なぜそれを行うのか(どのような観点か)の2つを考える。

想定されるシチュエーション

システム障害の時の調査用

この時に必要になるのが、主にログ。最低でも1~3ヶ月は保存しておきたいところ。 そして十丁なことが、障害発生時にどのポイントまで復旧できることを要件とするかが重要になるか。 またバックアップとパフォーマンスは対の関係である。

データ復旧

AWSでいうと、S3、Auroraなど

システム監査目的

AWSを想定すると、S3、Auroraのバックアップがあれば良いと思う。

システム運用の自動化

運用手順書も大事だけど、自動化できるところは自動化しちゃおう

セキュリティ

セキュリティ上の脅威

下記3つを守ることが重要。

• 情報の漏えい
• データの改ざんおよび破壊
• 業務サービス停止