読者です 読者をやめる 読者になる 読者になる

インフラエンジニアへの道 Amazon web services クラウドデザインパターン 設計ガイド

今日はAWSについて書きたいと思います。

snapshot(ある瞬間のデータを複製したバックアップ) パターン

➡データのバックアップ
課題:データの保存としてテープのバックアップをすると自動化が困難である。また、テープの容量が有限なため完全な自動化ができない。
 
解決策:クラウドでは安全で容量制限がないストレージがある。安い  プログラムを使用して自動化できる  OSごと複製できる
 
実装  EBSにスナップショット機能がついている ➡ S3に保存。 保存されたものはEBS上で新たに復元できる
     ブートディスクとして使うとAMIとして登録できる
 
利点・・・バックアップをプログラムから人手を返すことなく自動でできる
     バックアップ先に耐久性の高いS3
     EBSのデータを丸ごとバックアップできるので万が一の時にも簡単に復旧できる
     OSごとバックアップでき、AMIとして利用できるので、新たなEC2インスタンスを起動することも可能
 
注意点・・・スナップショットを取得する際にデータの整合性を確保しなければならない。

サーバーの複製
 
課題 仮想サーバーでも依然として物理サーバーと同じくらい設定の手間がかかる
      
解決  クラウド上でOSやミドルウェア、アプリケーションを設定でき、いつでも再利用できる
 
実装  OSブートがあるEBSからAMIを作成すれば、AMIからEC2をたくさん起動できる
 
利点
    仮想環境済みのAMIを使えば、それを基に立ち上げたEC2インスタンスへの設定作業は不要になる
    AMIは自分だけでなく、他人にもshareできる
 
注意点
    どの時点でのスナップショットを所得するか、どのくらいのタイミングでAMIを更新するかはケースバイケース
    バージョンアップやパッチは個別に行う必要がある

Scale up

 
動的なサーバーのスペックアップ
 
解決したい課題   サーバーの必要なリソースを自動的に補いたい
 
解決  クラウドではスペックに応じて切り替えることができる
 
実装  EC2インスタンスを起動してvmstatやcloudwatchでリソースを確認して、不足の場合はコンソールからインスタンスタイプを変更できる
 
利点   システムの設計時に厳密にサーバースペックを見積もらなくていい
     柔軟に対応でき、コスト面で無駄をなくせる
 
注意点
 
サーバースペックを変更するときには、EC2インスタンスを一時停止する必要がある。
インスタンスタイプの上限を超えることはできないので最も性能が高いインスタンスを選んで、scale out を採用するなど柔軟な対策が必要
 
処理待ちが大量に発生した時、一時的にサーバースペックを変更してその場をしのぎ、アプリやデータベースの改善をしてから元のスペックに戻す。
 

Ondemand Disk 

 
動的なディスクの容量の増減
 
ディスク容量を事前に見積もるのは難しいので、ハードウェアの初期投資が無駄になってしまう可能性がある
 
解決 クラウドでは仮想ディスクを利用できる  ➡いつでも好きなだけ容量を確保可能である。(オンでぃまんど)
                        ディスクは年々価格が下がっているので、いらなくなったら捨てるのが良い
 
実装  AWSのEBSを使えばいつでも好きなタイミングで容量を確保できる   
    ディスクが必要になった時にEBSスナップショットをとり、それを基に新しいEBSを作成する➡ 新しいEBSをEC2にアタッチする➡ リサイズコマンドで新しい容量まで拡張する
 
ストライピングのときは複数のEBSをアタッチし、ソフトウェアRAIDディスク構成にする
 
利点 コストの削減
   ストライピングを行うことでディスクI/Oの性能を上げる
 
注意点 EBSはS3と違い、確保したディスク容量に対して課金する (どれほどつかわれているかに関わらず)
 
EBSはネットワーク経由でアクセスするため、より大きいサイズのEC2インスタンスを利用するほうがI/O性能が高くなる

可用性向上
 
multi-server 
 
サーバーの冗長化
 
課題  複数の物理サーバーを用意する方法がある
    サーバー機器やロードバランサーなど、冗長化に必要な時は費用が掛かる
 
解決・・・・仮想サーバーを複数台並べ、クラウドにあるロードバランサを利用する(multi-server)
              オンプレより簡単に環境を整えやすい
 
実装  ELBを利用する  ELBはヘルスチェック機能があり、正常に稼働しているEC2だけに振り分ける
 
 ELBを複数のEC2インスタンスにひもつける➡ インスタンスのステータス確認を行う
 
利点
 
あるEC2インスタンスに障害が起きても、システム全体としては稼働を続ける
ELB auto-scaleを組み合わせれば、障害があっても一定のEC2を保てるので適切なAMIを選択してEC2を起動しておく必要がある
 
注意点
 
ELBと複数のEC2を利用するのでコストがかかる
常に予備がある構成にする   
 

IPアドレスの動的な移動
     
解決したい課題
 
サーバーにパッチを当てたり、アップグレードをするためにサーバーの停止が必要となる。 サーバー停止=サービスの停止   時間を短くしないといけない
 
解決 ➡ 従来では本来のサーバーの停止に備えて予備を用意するが、クラウドではこれがとても短くできる。
 
IPアドレスを指定するAPIもあるので サーバーの軌道からIPアドレスの設定までスクリプトを用いて自動化できる
 
実装  EIP(elastic IP address)  IPアドレスを付け替えられる。 EC2インスタンスに対してEIPを振り分ける
 
利点 EIPを付け替えるだけなので、DNSのTTLに影響されずにサーバーを切り替えられる。
    アップグレードの際、仮に切り替え先のサーバーでエラーが発生しても、即座に元のサーバーにEIPを付け替えることでフォールバックできる。
    EIPは別のAZにも適用できるのでリージョンごとに利用可能
 
注意点 
 EIPの切り替えには数十秒かかる
 VPCの場合、固定のプライベートIPアドレスを割り当てることができる。
 ネットワークカードを別のEC2インスタンスにも適用可能
 ただし、サブネットを超えてアドレスを付け替えることはできない