RASIS（Reliability, Availability, Serviceability, Integrity, and Security）
RASIS？最初見たとき、ライスだと思いました。DEMO、ごはんじゃありません。
説明も上手く出来なかったので、 一言で説明出来る ようにするために、整理しました。
| 項目 | 説明 |
|---|---|
| 信頼性 |
システムの壊れにくさを評価する指標 - ハードウェアとソフトウェアの両方において障害や不具合をゼロにすることはできませんが、最小限に抑えることは可能です。 - 平均故障間隔（MTBF）は、システムが安定稼働し続ける平均時間を示す指標。MTBFが長いほど信頼性が高いと言えます。 |
| 可用性 |
システムが障害などにより停止することなく稼働し続けることを指す - クラウド利用のメリットの一つとして重要視される。 - 稼働率はシステムの可用性を判断する指標であり、一定時間内でシステムが稼働可能な時間の割合を示す。 |
| 保守性 |
システムが機能や性能を維持できるかどうかを示す - ハードウェアではメンテナンスや修理の容易さ、ソフトウェアでは不具合修正や仕様変更の容易さが重要。 - サービスの停止時間が短いシステムは保守性が高いと評価される。 |
| 保全性 |
データの正確性や完全性を示す - 情報処理や電気通信の分野ではデータの欠損や不整合がないことを重視する。 - 情報セキュリティの分野ではデータの妥当性に注目する。 |
| 安全性 |
システムが利用するデータに対して高いセキュリティを維持することを指す - 外部からの不正侵入やデータ漏えいを防ぐために対策を講じる必要がある。 |
では、どうやって信頼性を維持するのでしょうか？
AWS Well-Architected フレームワーク 信頼性を例に、見ていきましょう。
https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.pillar.reliability.ja.html
5つの設計原則からなります。
| 設計原則 | 具体的な例 |
|---|---|
| 1. 障害から自動的に復旧する | Amazon Route 53の ヘルスチェックと自動フェイルオーバー を使用して、EC2インスタンスやS3バケットなどのリソースの障害から自動的に復旧する。 |
| 2. 復旧手順をテストする | AWSのCloudFormationやTerraformを使用してインフラストラクチャのコード化を行い、定期的に デプロイメントパイプラインを使用 して復旧手順をテストする。 |
| 3. 水平方向にスケールしてワークロード全体の可用性を高める | Amazon EC2 Auto Scaling を使用して、Webアプリケーションのインスタンスを自動的にスケーリングし、トラフィックの変動に応じてワークロード全体の可用性を維持する。 |
| 4. キャパシティーを推測することをやめる | AWSのCloudWatchを使用して、CPU使用率やネットワークトラフィックなどのメトリクスを モニタリングし、必要に応じてインスタンスの数やサイズを調整 してキャパシティを維持する。 |
| 5. オートメーションで変更を管理する | AWSのCodeDeployを使用して、アプリケーションのデプロイを自動化し、変更を管理する。また、AWS Lambdaを使用して、サーバーレスアーキテクチャを構築し、コードの実行とスケーリングを自動化 する。 |
これで、壊れにくい信頼性のあるシステムを構築するという事がどういう事か理解出来たと思います。