AWS(Amazon Web Services)ユーザが犯す間違いのトップテン

次の記事

企業のオープンソース利用–デベロッパたちに比べるとまだ後れている面も

amazon web services

編集者注記: Zev LadermanはNewvemの協同ファウンダでCEO。同社は企業等によるAWSの利用の最適化を支援している。

Amazon Web Services(AWS)は新興のスタートアップと一般企業のどちらにとっても優れたクラウドインフラの実装を提供している。料金が従量制で、高度な計算資源への普遍的なアクセスを提供し、利用者のニーズの拡大に合わせてスムーズにスケールできる、などの特徴がとくに美点だ。しかし欠陥は、使い慣れるまでの初期の難度が高いこと、AWSの利用を最適化しコストを抑えるために要する手間と時間が膨大になりがちなことだ。

弊社が非公開ベータで立ち上げた‘KnowYourCloud Analytics’サービスは、AWSのユーザがAWSの真実を知るためのツールだ。弊社Newvemは、ユーザ企業のさまざまな計算機資源から集めたデータを分析して、コストを切り詰められる場所、セキュリティの弱点のある場所、可利用性を現状より高められる場所、等々を同定している。

非公開ベータの立ち上げ以降弊社は、10万を超えるAWSのインスタンスをウォッチし、ユーザのクラウド運用がミスを犯しやすい状況を目撃してきた。それらのミスの一部は、シンプルだけどセキュリティや可利用性やコストの面で企業に大きな被害をもたらすものだ。

以下に、ユーザがもっとも犯しやすいミスのトップテンをご紹介しよう。AWSの費用効率の良い利用を実現するためには、まずこれらのミスの未然防止が重要だ・

  1. インスタンスのサイズが大きすぎる: AWSはインスタンスのさまざまなタイプとサイズを提供している。その柔軟性はけっこうなことだが、しかしユーザの多くが必要以上に大きなインスタンスを選んでいる。もちろんそれにより、無駄な費用が発生している。
  2. インスタンスの数が多すぎる: サイズの問題に加えてさらに、AWSには必要なだけ多くのインスタンスを動かせるという柔軟性がある。そこでユーザ企業があまりにも多くのインスタンスをクラスタやロードバランサで動かす、という結果になりがちだ。AWSはオンデマンドで利用できるから、ピーク負荷時に必要なクラスタノードのすべてを、最初から動かす必要はない。ノードは、必要に応じて増やせばよいし、しかもAWSには自動スケーリング機能がある。
  3. インスタンスタイプの選択における正しいトレードオフの欠如: AWSは多様なインスタンスタイプを提供しており、それらはインスタンスの使い方によって異なる(汎用サーバか、CPUあるいはメモリ集約的な負荷か、I/Oのパフォーマンスが重視されるか、サイズはどうか、など)。正しいインスタンスタイプを選ぶためには、アプリケーションの性格を正しく知るためのベンチマーキングが必要だ。しかし、適当にインスタンスタイプを決めるユーザが多いため、大きすぎて高価すぎるインスタンスを選んでしまいがちだ。リソースの利用状況をよく調べることにより、インスタンスタイプの選択に際して正しいトレードオフができるようになり(==何をいちばん優先すべきかの決定)、費用効率の最大化を図れる。
  4. インスタンスをアイドル運転のままにしておく: AWSのすばらしいアドバンテージは企業の運用ニーズに応じてインスタンスのサイズや数を柔軟に伸縮できることだ。サーバの加除は、シンプルなウィザードでできる。しかしこの柔軟性の副作用として、ユーザは往々にしてインスタンス数のチェックを怠り、offにすべきサーバをそのままにしがちだ。部屋を出るとき、電灯を消し忘れるように。無駄なサーバが動いているとアドミンの混乱を招き、プロセスの把握に時間がかかり、コストを無意味に押し上げる。
  5. 不要になったリソースの放置: クラウド環境では、使われなくなったリソースを放置すると管理の悪夢になりがちだ。AWSの従量制課金は理論的には立派でも、実践においてはリソースの無駄な使用がさまざまな問題の原因になる。たとえばEBSのボリュームはストレージの使用量で課金される。理想的には、将来必要となるボリュームだけを確保しておくことだ。将来計画にないボリュームをキープしたり、外し忘れたりすることによって、びっくりするような請求が舞い込み、管理者の頭痛を招く。
  6. EBSスナップショットの過少または無: AWSのいちばんクールな機能は、特定の時刻にEBSボリュームの仮想コピーを作れることだ。そのバックアップコピーのことをスナップショットと呼び、とくにデータの変更前の状態を取り戻せる点がありがたい。だから十分なスナップショットを取っておかないと、クラッシュなどによるデータの喪失時に泣くことになる。
  7. EBSスナップショットの過多: EBSスナップショットの取り方は、適切妥当でなければならない。しかし実際は、あまりにも多くのEBSスナップショットを取るユーザ企業が多く、バックアップの管理に混乱をもたらしている。課金は差分に対してしか発生しないが、だからといってスナップショットを濫用すると長期的にはストレージコストの無用な増大を招く。
  8. 割り当てたElastic IPの解放を忘れる: Elastic IPは使わなくても課金されるが、そのことをユーザは忘れがちだ。費用は1時間数セントぐらいだから、無視してしまうユーザも多いが、それがあれこれ合わせて数百ともなると、各年で数千ドルの費用を発生させてしまうだろう。
  9. セキュリティグループの構成の不適切: AWSユーザの多くがクラウドインフラの構成を誤って、セキュリティの欠陥や脆弱性を招いている。それらの欠陥の多くがネットワークに穴を開け、システムをセキュリティの脅威にさらすことになる。
  10. Availability Zoneを複数にしない: AWSの‘Availability Zones’は、ユーザの作業負荷を一定の区域内で複数のデータセンターに分散するという、単純な機能だ。これは万一の停電や災害等に対するリスク軽減のための、きわめて効果的なソリューションであるが、残念ながら実際に停電を経験するまでは、負荷の分散を考えないユーザが多い。

〔訳注: 本稿を、あまりにも一般的、あまりにも当たり前、と感じた読者は、原文のコメントなどを手がかりに、より詳細でより具体的な「賢いAWSユーザ」情報にアクセスされることを、おすすめします。たとえば、本当の最適化ソリューションはアドミンのレベルでなく、“AWS的アプリの書き方”にあるとか。〕

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))