amazon web service使ってみての雑感

Posted by roadman on Tuesday, May 14, 2013

TOC

  • 先日、会社で担当していたサービスを一挙にaws(amazon web service)に移管しました。
  • EC2、ELB、VPC等々、サービス運用に必要なソリューションを一通り使ってみたのでなんとなく雑感的な物を共有しておこうかと。

awsって何?

  • 先ほども書きましたが、amazonが全世界向けに提供しているクラウドサービスです。
  • amazon web serviceというのは数十個の個別のクラウドソリューションの総称で、およそwebサービスを展開するのに必要なほとんどのプラットフォームがまかなえます。実際、必要なプラットフォームを全てamazon web serviceで構築している会社も割りといるようです。
  • 代表的なソリューションとしては…

    Amazon Elastic Compute Cloud (EC2)
    Amazon Simple Storage Service (S3)
    Elastic Load Balancing (ELB)
    Amazon Route 53
    Amazon Virtual Private Cloud (VPC)
    Amazon CloudWatch
    
  • …などでしょうか。

  • 他にも把握できないほどのソリューションがあります。

  • 他にも、ビックデータの解析によく使われるHadoopのプラットフォーム「Amazon Elastic MapReduce」とかもあります。

  • ビックデータの解析に必要なプラットフォームは、スモールスタートするには大きなコストになりがちですが、amazonを利用することでカバーできます。

  • じゃあ既存のレンタルサーバとかはもういらないの?と、言われると、それはそれで用途や費用感にもよるので一概には言えないのですが、今までサーバ会社の独壇場だったところに、amazon web serviceの出現で激震&価格破壊が起こっているのは確かだと思います。

awsのメリット

  • スモールスタートが可能で、構築も早い
  • インフラは全てクラウド上に構築されていて、使うために面倒な準備期間がいりません。 amazonの用意している管理画面から手順にしたがって操作すればすぐにサーバが用意されて利用可能になります。
  • また、サーバのスケールアップ(要はCPU性能を良くしたり、メモリを増やしたり)も、管理画面からの操作で可能。
  • 物理サーバを使う時のように、サーバセンターに連絡して新しいサーバを用意してもらって等々で数日〜数週間とかいうタイムラグもなく、5分もあれば終わります。
  • なので、最初から高くて性能のいいサーバを用意する必要もなく、まずは安価なサーバを用意してサービスを開始、成長に合わせてサーバをグレードアップすることが簡単にできるのです。

インフラコストの低減

  • これはサーバ会社にもよるので一概には言えないところですが、amazon上に構築したクラウドサーバの費用は、一般的なレンタルサーバ会社が用意する同性能のサーバの費用に比べて高いということはなく、大抵の場合安いです。
  • また、レンタルサーバのように年や月で契約することはなく、完全従量課金なので使用をやめたいときにも即日辞められます。なので、サービスがこれから継続するかどうかわからないスタートアップとかにとっては、費用的なリスクを抱え込まずにすみます。
  • 回線費用については、inputについてはほぼタダ、ほとんどはoutputのトラフィック量での請求になります。こちらについてはサービスにもよりますが、ビデオを配信するとか大容量のデータを配信するとかでもない限りは、帯域保証で契約した場合よりは安くなるかと思います。

運用コストの低減

  • 正直これがかなり大きいです。
  • まず、サーバの構築や設定変更、グレードアップといったことが簡単に管理画面orAPIから行えるというのが大きい。
  • サーバのコントロールのほとんどもAPIから行えるため、ちゃんとスクリプトを書けば運用のかなりの部分を自動化できると思います。
  • また、新規サーバの構築がAMIと呼ばれるサーバのイメージを作っておくと、同設定のサーバであれば数分で終わるのもかなり楽です。
  • サーバの準備も構築も数分で終わるため、サービスに急にリクエストが増えた場合も、新しいサーバがくるまで数日間はアラートに怯えながら、またアラートが来た場合は寝食を削って対応する…などという悪夢(しかしよくある)にさらされことないく、すぐにサーバをスケールして対応することができます。

高いスケーラビリティ

  • 上の項目でも書いたことですが、サーバの構築は簡単なのでサーバパフォーマンスのスケーラビリティがかなり高くなります。
  • また、回線についてももともとamazonが持っている大規模回線の一部を従量性で使っているだけなので、ほぼ帯域が足らなくなる可能性はないです。  ELB(amazonの提供するロードバランサー)も、デフォルトで自動スケールしてくれます。

稼働率

  • 過去の実績を見てもレンタルサーバのサーバセンターより低いということはなく、一部のソリューション(Route 53というDNSサービス)などでは稼働率100%(!)をうたっています。

世界展開するサービスでの使いやすさ

  • 世界展開するサービスでは特に大きいのです。
  • 海外にサーバを置きたいサービスなどでは、各国のサーバ会社と個別に契約する…とかは、中小の会社ではまず無理でしょう。
  • amazon web serviceは世界展開されているクラウドソリューションなので、これも管理画面上からアメリカやヨーロッパなどといった地域でサーバを用意することができます。

awsのデメリット

性能が完全に保証されているわけではない

  • サーバについてはよくよく起動したサーバのcpu性能等々を見てみると、同じインスタンスタイプでも微妙に性能差(cpuのクロック数が数%違うとか、cpuの一次キャッシュの量が違うとか)があります。
  • おそらく、クラウドサーバなので実際に起動している物理サーバが違うことによるのでしょうが、ロードバランサーとかで並べると微妙に負荷とかが違ったりして少し使う時は注意が必要です。

完全従量制

  • 完全従量性、ということでアクセス量次第では請求額が跳ね上がる…という危険性もないとは言えません。
  • このあたりはアラートを出す設定があったりもするようで、気を付けて使いたいところです。
  • 一応、前日分までの費用は画面から確認できますので毎日のウオッチは必須かと。

amazon都合でのサーバ再起動とか

  • 今のところ経験していませんが、たまにamazon都合のメンテナンスとかでサーバの再起動があったりするようです。
  • これは普通のレンタルサーバでもあることはありますが、頻度的にはamazonのほうが多い…というような話も聞きます。
  • ただ、行われるのは物理サーバ単位のようなので、事前に告知があった時点で、サーバを起動し直せば大抵は他の物理サーバに切り替わって大丈夫になるようです。

ELBの自動スケールアップが遅い

  • また、夜間のピーク時の数時間だけELBのキャパをオーバーしてしまうような場合は、そもそもELBのスケールが間に合わず、毎日ピーク時はキャパオーバー(ELBのグラフをモニタリングして、503エラーとかをELB自体が出しているような場合)を起こすようなことにもなりかねません。
  • ELBのスケールリングは、最初は1台のサーバがスケールアップ(性能アップ)していき、1台で収まらなくなったらスケールアウト(nslookupとかでELBのDNS名を引くと、DNSラウンドロビンしていて複数台になっているように見える状態になるとスケールアウトして台数をどんどん増やしている)していきます。
  • あらかじめ負荷が増えることが分かっている場合は、あらかじめ自分で負荷を与える(abとかでガンガンリクエストしまくるとか)ことでスケールアップさせておくか、お金に余裕があるなら、サポートプランをビジネスにして、サポートにpre-warmの依頼をする(すぐに対応してもらえます)かです。
  • 個人的には、pre-warmが必要な場合だけビジネスプランにして、必要なくなったらビジネスプランをやめるとかもありかと思います。

最後に

  • 簡単ですが、amazon web serviceについて説明させてもらいました。