クラウドコンピューティングといえば仮想サーバ
ないと話にならないものの１つ、仮想サーバ。AWSではAmazon EC2 (安全かつスケーラブルなクラウド上の仮想サーバーホスティング)という。ほとんどのケースでこれを使うので、いろいろな仕掛けがあって結構複雑、試験でもよく聞かれるので、「こんな仕掛けだからこういう動きになるんだろうなぁ」という感じで、正確さを犠牲にしてまとめてみる。
EC2の仕組み
想像力全開で考えてみる。
EC2 Consoleからポチポチやってインスタンスを起動させると、適当なサーバ上にインスタンスがポコっとできてくる。
AWS CloudWatch（クラウドとネットワークのモニタリング）でどうしてメモリの状態が標準メトリクスで見れないのかというと、メモリは立ち上がったインスタンスの中の状態だから。スーパーバイザー(サーバ)で取得できるメトリクスは標準メトリクスとしてサポートするけど、中のことまでは面倒みれないということだろう。インスタンスに割り当てたメモリならスーパーバイザーでもわかりそうだけど、そんな情報、ユーザーには役に立たないし。
インスタンスストア
サーバについている(ローカル)ディスク。
Instance Store-Backed
他社のVPSサービスから移ってきて戸惑うことの1つが、これ。Amazon EBS-Backed と Instance Store-Backed と言われても、「なんのこっちゃ？」となる。
普通に使う分にはEBS-Backedだけ考えていればいいが、試験対策ではちゃんと理解していないといけない。
インスタンスのルートデバイスが図のローカルディスクにあるのが、Instance Store-Backed AMI。インスタンスを起動させるとき、動かすサーバは適当に選ばれるので、ローカルディスクにAMIのディスクイメージは存在していない。なので、S3からローカルディスクにコピーして、それを使って起動する。ネットワーク経由でコピーしないといけないから、立ち上がりは遅い。遅いが、立ち上がってしまえば、そこはもうローカルディスク。速い。
終了すれば消えるディスク
インスタンスが終了したら、コピーしてきたディスクイメージはもう用なし。なので、さっさと消して、他のインスタンスのためにディスクを空ける。
インスタンスの停止状態をサポートすると、同じサーバでインスタンスを再び動かさなければならないし、停止時のディスクの内容を保持しておく必要があるから、貴重なローカルディスクが無駄になってしまう。だから、Instance Store-Backed AMIは、停止状態がサポートされていないんじゃないかなぁ。サイズが10Gまでというのも、無駄に確保されないためのように見える。
EBS
インスタンスストアに対して、EBSというものがある。
ローカルディスクの代わりにネットワークディスクを使う。
ネットワークディスクを意識するのはあくまでサーバで、その上で動くインスタンスからはローカルディスクの様に見えるのがポイント。
EBS-Backed
インスタンスのルートデバイスの実体が、ネットワークディスク上にあるのが、EBS-Backed AMI。インスタンスを起動させるとき、サーバを適当に選んだ後、ネットワークディスクにアクセスすれば良いので、立ち上がりは速い。が、所詮ネットワーク経由なので、速度はそれなり。
インスタンスから見えないところで小細工(暗号化)できる
インスタンスからはローカルディスクとして見えるが、実体はネットワークディスクである。サーバ(スーパーバイザー)が間に入って処理をしているのだ。ということは、サーバが暗号化しても、インスタンスからはわからない。EBS暗号化だ。
ディスクをつなぐときに、暗号化する/しないを決めてやるから、途中で暗号化するように設定を変えることはできない。逆に、つなぐときに決めるから、暗号化するディスクとしないディスクを同時に使うことができる。
スーパーバイザーが暗号化を行うので、インスタンスの性能には影響を与えないし、EBSの種類にも左右されない。ただし、暗号化でサーバのパワーを使ってしまうので、サポートされないサーバ、というか、インスタンスがでてくる。
ネットワークが狭い？
EBSはネットワークディスクだ。ということは、頻繁にアクセスすると、それだけネットワークの帯域を喰ってしまう。場合によっては、ネットワークが性能のボトルネックになってしまうことも、あり得る。
そのための対策が、EBS最適化インスタンスだ。EBS用に、別途ネットワークの帯域を確保してくれる。
公式情報で確認を
今回は特に、イメージ優先でそれっぽいことを書いたので、必ず公式情報で確認してほしい。
コメント