世界で最も利用されているクラウドサービスの一つであるawsでは、運用チェックリストという独自のツールが用意されています。これは、「チェックリスト」となっていますが、一通り目を通すことによって、awsを使ってシステムを構築・運用する上で知っておくべき基本的な知識が詰まっています。
awsに関わるエンジニアは一度は読んでおくべきものであるため、以下ではその内容の一部を簡単に見ていくことにします。
担当者別IAMユーザーの使用法
「AWS上で環境を構築するにあたりパスワードや鍵などの認証情報であるクレデンシャルを共用せず、ユーザーごとのIAMユーザーを使っているか？」というのが一つ目のチェック項目です。これが意味するところは、IAMユーザーを複数人で共用するのは危険であるということです。
もしIAMユーザーを共有していると、万が一セキュリティ関連の事故が発生した場合に、CloudTrailを使ってログを追跡したとしても個人を特定することができなくなってしまいます。情報セキュリティの世界では、情報を共有すればするほど安全性が低くなるということは常識ですので、IAMユーザーを他者と共有することは原則として避けた方がよいでしょう。
ストレージタイプの選択方法
チェック項目の二つ目は、「Amazon EBS-Backed と Instance Store-Backedインスタンスは何が違うか？またそれらによるデータの永続性やバックアップ、リカバリーの違いを明確に理解して、インスタンスを適切に選んでいるか？」というものです。
両者の違いは、インスタンスがストップした場合にそこに格納してあるデータが消去されるか否かです。Amazon EBS-Backedに格納しているデータは基本的に消去されることはありませんが、もう一方のInstance Store-Backedに格納しているデータは簡単に消去されてしまいます。
そのため、インスタンスがストップしてもデータを失いたくないという場合にはEBSを利用することをお勧めします。
また、料金がかからないEphemeralディスクは、一時的にファイルを置いておいたり、スワップファイルを格納しておくのに適しています。
動的なIPアドレスの仕組み
チェック項目の三つ目は、「AWSに組み込まれている動的なIPアドレスの仕組みを理解しているか？また、アプリケーションの構成要素を再起動しても正常に機能することが保証されているか？」というものです。この項目について知っておきたいことの一つは、Public DNS/Public IP addressと呼ばれるEC2の動的グローバルIPは、インスタンスを再起動した場合にはIPアドレスが変わってしまうということです。
そのため、外部に対してサービスを公開しようとする場合は、ELBやElastic IPといったIPアドレスが変わることのないものを使用した方がよいでしょう。
データ領域用EBSを利用する
チェック項目の四つ目は、「EBSをシステム領域とデータ領域とで分けて使用しているか？」というものです。EBSをシステム領域として使用する場合、その中身を拡張するためには非常に複雑な手順を踏まなければなりません。
そのため、EBSをシステム領域とデータ領域で共用していると、システム領域を拡張するためにデータ領域にまで大きな影響を及ぼす可能性があるため、なるべくであれば両者は別々にしておいた方が賢明です。もちろん、一緒のEBS上にシステム領域とデータ領域を設けることは理論上は可能ですが、あとからシステムの拡張性が著しく制限されることになりかねないという点に注意しておく必要があります。
バックアップしているか
チェック項目の五つ目は、「EBSに内蔵されているスナップショット機能やそれ以外のバックアップツールなどを使って、定期的にEC2をバックアップしているか？」というものです。awsに限らず、定期的にデータのバックアップを取っておくことはエンジニアにとっての基本といっても過言ではありません。
もしバックアップを取っていない状態で、万が一システム障害が発生してデータが消滅したり、破損するようなことがあれば、いくら高機能のシステムであったとしても元のデータを復旧させることは非常に困難です。awsでは簡単でしかも安価にデータのバックアップを取ることができる仕組みが用意されていますので、積極的にこれを使ってデータをバックアップしておくようにしましょう。
リストアとリカバリ手順を確認する
六つ目のチェック項目は、「障害に備えてGolden AMIという独自AMI、EBSスナップショット、ブートストラップ方式、自前のバックアップ・リカバリツールなどを用いて定期的にEC2インスタンスやEBSをリカバリする手順をテストしているか？」というものです。
システムには障害がつきものですので、もし何らかのトラブルが発生した場合に、いかに迅速にそれを解決するかが重要となります。この点、システムの本番運用が始まった後では、トラブル時のリカバリテストを行うことは難しくなるため、運用開始前の段階で様々なトラブルの発生を想定してそれらのリカバリ手順を確認すべくテストを行うことは必要不可欠です。
念には念を入れて徹底的にテストを繰り返しておけば、実際に運用してからトラブルに見舞われても安心というわけです。
重要データは分散して配置する
七つ目のチェック項目は。「アプリケーションにとって重要となるEC2やデータなどのコンポーネントはマルチAZに分散配置されているか？ゾーン間で適切にデータレプリケーションしているか？コンポーネントにトラブルが発生した場合にどういった異常が生じるかテストしているか？」というものです。
コンポーネントが停止してしまった場合に、アプリケーションの機能に大きな影響を及ぼすようなことがあってはならないため、そういったコンポーネントは原則として複数AZに分散して配置しておくことが求められます。
十分にコンポーネントが分散していないようなシステムは、非常に脆弱なものとなるため、システム構築時にはどれが重要なコンポーネントかをしっかり見極めて分散配置するようにしましょう。
システムの冗長性について
八つ目のチェック項目は、「マルチAZに配置されているEC2やデータなどのコンポーネントがフェイルオーバーする仕組みを理解しているか？また、サードパーティの製品やElastic Load Balancing、Elasitic IPを適切に使用しているか？」というものです。
どのようにコンポーネントがフェイルオーバーするかを知っておくことは、障害が発生した場合に原因箇所を素早く特定するために大切なことです。そのため、システムに使われている各コンポーネントの仕組みをしっかりと理解し、場合によっては意図的に障害を発生させてフェイルオーバーがどのように起きるかを確認しておくことが重要となるでしょう。