インフラエンジニアへの道 Amazon web services クラウドデザインパターン 設計ガイド
今日はAWSについて書きたいと思います。
snapshot（ある瞬間のデータを複製したバックアップ） パターン
➡データのバックアップ
課題：データの保存としてテープのバックアップをすると自動化が困難である。また、テープの容量が有限なため完全な自動化ができない。
解決策：クラウドでは安全で容量制限がないストレージがある。安い プログラムを使用して自動化できる ＯＳごと複製できる
実装 ＥＢＳにスナップショット機能がついている ➡ Ｓ３に保存。 保存されたものはＥＢＳ上で新たに復元できる
ブートディスクとして使うとＡＭＩとして登録できる
利点・・・バックアップをプログラムから人手を返すことなく自動でできる
バックアップ先に耐久性の高いＳ３
ＥＢＳのデータを丸ごとバックアップできるので万が一の時にも簡単に復旧できる
ＯＳごとバックアップでき、ＡＭＩとして利用できるので、新たなＥＣ２インスタンスを起動することも可能
注意点・・・スナップショットを取得する際にデータの整合性を確保しなければならない。
サーバーの複製
課題 仮想サーバーでも依然として物理サーバーと同じくらい設定の手間がかかる
実装 ＯＳブートがあるＥＢＳからＡＭＩを作成すれば、ＡＭＩからＥＣ２をたくさん起動できる
利点
仮想環境済みのＡＭＩを使えば、それを基に立ち上げたＥＣ２インスタンスへの設定作業は不要になる
ＡＭＩは自分だけでなく、他人にもshareできる
注意点
どの時点でのスナップショットを所得するか、どのくらいのタイミングでＡＭＩを更新するかはケースバイケース
バージョンアップやパッチは個別に行う必要がある
Scale up
動的なサーバーのスペックアップ
解決したい課題 サーバーの必要なリソースを自動的に補いたい
解決 クラウドではスペックに応じて切り替えることができる
利点 システムの設計時に厳密にサーバースペックを見積もらなくていい
柔軟に対応でき、コスト面で無駄をなくせる
注意点
サーバースペックを変更するときには、ＥＣ２インスタンスを一時停止する必要がある。
処理待ちが大量に発生した時、一時的にサーバースペックを変更してその場をしのぎ、アプリやデータベースの改善をしてから元のスペックに戻す。
Ondemand Disk
動的なディスクの容量の増減
ディスク容量を事前に見積もるのは難しいので、ハードウェアの初期投資が無駄になってしまう可能性がある
解決 クラウドでは仮想ディスクを利用できる ➡いつでも好きなだけ容量を確保可能である。（オンでぃまんど）
ディスクは年々価格が下がっているので、いらなくなったら捨てるのが良い
実装 ＡＷＳのＥＢＳを使えばいつでも好きなタイミングで容量を確保できる
ディスクが必要になった時にＥＢＳスナップショットをとり、それを基に新しいＥＢＳを作成する➡ 新しいＥＢＳをＥＣ２にアタッチする➡ リサイズコマンドで新しい容量まで拡張する
ストライピングのときは複数のＥＢＳをアタッチし、ソフトウェアＲＡＩＤディスク構成にする
利点 コストの削減
ストライピングを行うことでディスクＩ／Ｏの性能を上げる
注意点 ＥＢＳはＳ３と違い、確保したディスク容量に対して課金する （どれほどつかわれているかに関わらず）
ＥＢＳはネットワーク経由でアクセスするため、より大きいサイズのＥＣ２インスタンスを利用するほうがＩ／Ｏ性能が高くなる
可用性向上
multi-server
サーバーの冗長化
課題 複数の物理サーバーを用意する方法がある
オンプレより簡単に環境を整えやすい
実装 ＥＬＢを利用する ＥＬＢはヘルスチェック機能があり、正常に稼働しているＥＣ２だけに振り分ける
利点
あるＥＣ２インスタンスに障害が起きても、システム全体としては稼働を続ける
ELB auto-scaleを組み合わせれば、障害があっても一定のＥＣ２を保てるので適切なＡＭＩを選択してＥＣ２を起動しておく必要がある
注意点
ＥＬＢと複数のＥＣ２を利用するのでコストがかかる
常に予備がある構成にする
ＩＰアドレスの動的な移動
解決したい課題
サーバーにパッチを当てたり、アップグレードをするためにサーバーの停止が必要となる。 サーバー停止＝サービスの停止 時間を短くしないといけない
解決 ➡ 従来では本来のサーバーの停止に備えて予備を用意するが、クラウドではこれがとても短くできる。
ＩＰアドレスを指定するＡＰＩもあるので サーバーの軌道からＩＰアドレスの設定までスクリプトを用いて自動化できる
実装 ＥＩＰ（elastic IP address) ＩＰアドレスを付け替えられる。 ＥＣ２インスタンスに対してＥＩＰを振り分ける
利点 ＥＩＰを付け替えるだけなので、ＤＮＳのＴＴＬに影響されずにサーバーを切り替えられる。
アップグレードの際、仮に切り替え先のサーバーでエラーが発生しても、即座に元のサーバーにＥＩＰを付け替えることでフォールバックできる。
ＥＩＰは別のＡＺにも適用できるのでリージョンごとに利用可能
注意点
ＥＩＰの切り替えには数十秒かかる
ＶＰＣの場合、固定のプライベートＩＰアドレスを割り当てることができる。
ネットワークカードを別のＥＣ２インスタンスにも適用可能
ただし、サブネットを超えてアドレスを付け替えることはできない
