AWSガイドラインを少しずつ考えていきます。
完成するのはずっと先の話になると思いますが常にブラッシュアップしたいと考えています。
ガイドラインとグランドデザインの違い
たまにどっちだっけ…？と迷うことがあるので違いについて。
- ガイドライン ← ルールなど守るべきことについてどう行動するのかの指針。guideline（方針、指針）
- グランドデザイン ← 壮大な設計、壮大なプロジェクト。
- 指針 ← 向かうべき方向を示す方針
ガイドラインは作って終わりではなく改善が必要
ガイドラインは1回作って終了ではなく、PDCA サイクルを回して改善していくことが重要です。
特に実際にやってみてからのフィードバックが重要になります。
環境について
環境は3つ用意する（本番（prd）、ステージング（stg）、開発（dev））
命名規則について
最初に命名規則を決めておくと後から当初は想定しなかった追加が発生しても命名がバラバラになることはありません。
逆に最初に命名規則を決めておかないと、この環境は大文字だけのホスト名だけど、この環境は小文字だけのホスト名になるなど運用でミスが発生しやすい環境になるリスクがあります。
コード化について
構築方法をコード化する（手作業で構築しない）
しかしインフラをコード化（Infrastructure as Code）できれば理想ですが限度があります。
どこまで追求するか妥協点を決める必要があります。
ネットワーク環境について
クラウドの最大の利点を活かすためにIPアドレスやホスト名でも管理しない設計を考えておくといいでしょう。
セキュリティについて
コードにアカウントやパスワードを直書きしないようにします。
AWSの場合は、SSM（Systems Manager）のパラメータストアの暗号化コンテキストを利用します。
デプロイについて
可能な限り手作業をなくします。例えばExcelファイルで作成した手順書をコピペしながらTera Termなどにペーストをして実行するなどの作業です。
デプロイする際は各サーバにファイルやアプリケーションを配布したりインストールするのではなく、すでに配布済み、インストール済みの AMI を展開することでサービスの停止時間をできる限り短くします。
EC2インスタンスをステートレス化する
EC2インスタンスは必ず Auto Scaling グループと ELB で管理します。
1台構成でも Auto Scaling グループと ELB で管理します。
Auto Scaling グループを利用するということは、AMI から起動してそのまま EC2 インスタンスとして利用できる状態ということになります。
その為、ステートレス化する必要があります。
ステートレス化とはサーバ上に状態をもたないことを言います。
コメント