AWSの経験、4ヶ月が経ち、振り返ると大変貴重な経験を積ませてもらいました。
SESで本来は即戦力にならなければならないといけませんが
現場のPM、リーダーの方にはとてもお世話になっています。
いくつかタスクが割り振られていますがその中でとても濃い経験になったのは、やはり設計・構築のタスクです。
ある程度、SAAで知っていたものの、実践してみると全く違います。
構成図のパワポから必要なサービスを洗い出し、命名規則から一緒に取り組む経験ができました。
はじめてのAWS設計と構築で僕の覚えている範囲で学んだことをシェアしたいと思います。
どんな環境だったか
今回は開発環境の構築、踏み台サーバをパブリックサブネットに設置
プライベートサブネットに５つのサーバーを設置
もう一つのプライベートサブネットにRDSを設置する。
AZ障害を防ぎたいのでサブネット３つ×AZ２で作成する必要する。
極めてシンプルな設計です。
利用したサービス
・EC2
・RDS
・S3
・SNS
・CloudWatch
・EventBridge
・IAM
AWSの基本的なサービスだけですね。
構築を進めるにあたり気をつけるポイント
・今回の案件は某大手企業の開発環境の構築、規模としては小さいものだが場合によってはひとつの設定で数百万、数千万の損失を生むので慎重に行うこと。
・設計書の項目と実機で設定する項目に差異がある。もしくは怪しい点があれば調べること。少しでも気になることがあれば必ず確認すること。
・設計書に記載する項目は必ずコピペで行うこと。手入力は間違う可能性が大きい。
・再監者と声出し確認を行いながら進めること。
・設計する前に命名規則のルールを作成しておくこと
命名規則について
設計を始める前に大切なのが命名規則。ひとつの設定を行うのに他の設定と被ってはいけないし適当につけてしまうと後に面倒なことになる。
命名規則は環境や設定するリソースによってそれぞれの命名規則のルールを作成しておく。
例えば、ルートテーブルの命名規則
環境識別子-システム識別子-利用用途識別子-AWSリソース識別子-サブネット種別-AZ種別
このようなルールで命名するなら・・
↓
開発環境_〇〇システム_検証用_ルートテーブル_プライベートサブネット_東京リージョンAZ1
↓
dev-sys-test-rt-pri-01
このようになる。
サブネットの設定について
サブネットを切るときは必ず他のチームに聞いておくこと。
他の環境と被らないためにサブネットが切る必要があるし、そもそも設定使用するときにエラーが出る。
ピアリングを接続する条件としてサブネットのIPアドレスは他の環境と被らないことが前提である。
障害対策でマルチAZにする。今回はパブリック、プライベート、データーベースのサブネットが必要となる。
そして障害対策としてマルチAZにするため合計６個のサブネットが必要になる。
ルートテーブルの設定について
・パブリックルートテーブルの設定
・プライベートルートテーブルの設定
・データベースルートテーブルの設定
基本的にこの三つを設定する必要がある。
●パブリックのルートテーブルの場合
・インターネットゲートウェイへの設定
・プライベートサブネット（開発用のサーバーがあるサブネットとRDSを設置しているサーバーこの二つがあります。）
パブリックのルートテーブルに関してはこの三つを設定する必要がある。
●プライベートのルートテーブルの場合
開発環境へのルートとローカルへのルートとなる
データベースのルートテーブルはデータベースからローカルのみのルートとなります。
EIPを設定するポイント
パブリックサブネットに設定する。グローバルIPに割り振っておけば外のネットワークと通信するのに必要という側面と外部から処理を実行するときに必要だから
RDSの設定について
RDSにEIPを割り振ることはできません。IPアドレスは動的になります。
今回の場合、RDSは普通に作成したら指定したIPアドレスの範囲はサブネットはどこに作ろうか？という設計するが今回は顧客から指定されたIPアドレスはない。
（ちなみにピングを打って返ってくるか確認しておく）
そもそもRDSは指定された範囲のサブネットグループの中でしか起動することはできない.
「この範囲で作っておいてね」と設計者が指定した範囲のサブネットを決めておけば動的に立ち上がるものである。
何か障害が起きた場合、勝手に停止してまた起動して違うIPアドレスで立ち上がるリソースである。
RDSにアクセスする場合はエンドポイントを作っておいて、指定したサブネットグループのIPアドレスにアクセスされるという仕組みである。
だからRDSを作成する前にサブネットグループを作成しておく必要がある。→起動するサブネットが決まっていないため。
ストレージの自動スケーリングについて
DBの容量をマックスで使用する場合、自動的にRDSの方で容量を増やすこと。使用する容量が少ない場合は減らしていくこと。
今回は見積もりに入っていないのでストレージの自動スケーリングは無効にしている。
毎日閾値調査をしている。閾値に引っかかったらそれをレポートで提出している。
たとえば月の頭に10GB使用していて、30日になったら60GBになったら？というパターンであれば
どのくらい伸びていくかがわかるようになるし、
どれぐらいで枯渇するかもわかるようになるのでそれをお客様に拡張しますか？どうします？といったふうに提案していく。
すでに運用していけば大体1年後、どのくらいの容量を使用するのが見えてくるので
課題として追加しておいて時期がきたときに提案をしていく。いきなり言われたとしてもお客さんも「お金どうするの？」って話になるので、ある程度の見通しを立てておいてお客さんに伝えておくと親切なSEである。
レポートの役割は使用率をみてて事前に問題があるかないかを把握するための資料である。問題があるならもっと手前で知らせる必要がある。
一応ストレージの自動スケーリングの閾値も決めることができる。今回は無効にしているのでナシ。
EC2の設定について
基本的にはLinuxサーバを使用する、Windowsサーバと比較して料金がやすいため、しかし踏み台サーバーはWindowsサーバを利用する。Windowsでしか使えない機能もあるため。
インスタンス起動時にはネットワークインターフェースデバイス名は自動で設定されるが後で変更することができる。
EC2のオートスケーリングについて
どんな条件でサーバー自動で増やしているのか？オートスケーリングのスケーリングポリシーにある。
メトリクスタイプで平均CPU使用率の項目を設定したり平均ネットワーク入力、出力などを選択することができる。
また、ターゲットごとのアプリケーションロードバランサーのリクエスト数などの項目を選択してターゲット値を入れることで設定することができる。
例としてアパレル企業であればセールがあるのでその都度、アプリケーションロードバランサーのリクエスト数が増えるので、そのときにターゲット値を超えた場合にサーバーを増やすことができる。
サーバーでも何かしらの処理が動いている場合もあるのでCPU使用率が上がったりする、だからALBのリクエスト数だけを見るのは良くない。
例としてウイルススキャンなど裏で動いているものがあるのでこれだけに限らない。
グループサイズで最大容量と最小容量というふうにサーバーの台数まで設定することができる。
スケールアップとスケールダウンの違い
SAAでも学んだことだがインスタンスタイプを変えてCPUやメモリのサイズをあげるのがスケールアップでありスケールダウンである。
スケールアウト・インがサーバーの数を増やしたり減らす。
S3の設定について
S3はグローバルなストレージサービス。どこのリージョンに設定することが選べる、基本的は外部からでもアクセスできるようにグローバルに設置したりする。
グローバルに設置する場合は他と被ってはいけないので他と被らない命名規則にする。
S3のバケット名は自動でつくので後に設計書で記載されているものに変更する。
S3スナップショットは静止点をつけてバックアップを取っている。静止点においてはそこでデータが動作しているという言葉は基本使わない。動作をとめている撮るという認識
ストレージデバイスとストレージでデバイス-ルートについて
ルートデバイスはWindowsのシステム領域のCドライブのことを指す。システム系の保存先というイメージ。
Cドライブの空き容量が少なくなったりするとシステムが不安定になったりする。
その場合は、外付けのハードディスクやUSBメモリなどを使用して空き容量を増やしていく必要がある。
AWSでは「ストレージデバイス-ルート」と言われる
EBSはDドライブ。Dドライブは画像や動画、音楽などのアプリケーションで作成したデータ転送などの保存先として利用される。
EC2のクレジット仕様について
T系インスタンスにある設定項目の一つ。このクレジット仕様について三つの概念がある。
●ベースライン・・ベースラインとはT系インスタンスにあらかじめ決められているCPU使用率のことを指す。
●バースト・・ベースラインを超える、もしくは本来の性能をあげることをバーストという。
●クレジット・・CPUがバーストされたときに消費するポイントみたいなもの。RPGゲームで言うところのMP。
このクレジット残高が0になると後述薄る消費タイプにより性能が下がる、もしくは追加の課金が発生する。
たとえば、1000のクレジットがあるとする。
１時間で300のクレジットが消耗されるとしたら
３時間と20分だけバーストできる。これが0のまま続くと課金されてしまう。
仮にバーストしてクレジットが0のまま続いたらその課金分は顧客持ちになるから基本的にはベースラインで考える。
SNSの設定について
サブスクリプションとして設定できるものはメール以外にもSSMautomation、lambdaだったり設定できる。
データセンターのメールサーバの設定次第ではSNSでメールが届くように設定しても届かないことがある。顧客に承認を求める必要がある。