CM re:Growth 2014 TOKYOで運用目線でAWSって素晴らしいって話をしてきた #cmdevio

2014.12.18

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

2014年12月16日に行いました、CM re:Growth 2014 Tokyoに参加しました!
物理サーバを運用していて思った事AWSを使うことによって運用も変わってきたなぁと思ったことを発表しました。

あのときAWS環境だったら…

[slideshare id=42781104&doc=devio-mtup11-tokyo-012-141216220210-conversion-gate01]

内容

物理サーバでの対応とAWSでの対応の違いについて運用目線で話しました。

サーバ再起動のとき

  • IDCにサーバを預けていた時はサーバ再起動に時間がかかっていた。
    • 障害受付センターへ電話→現地作業員からの折り返し待ち
  • AWSだと
    • マネージメントコンソールに入ってstop→start

サービスへの影響時間も減少しました。

DISK容量が足りなくなってきたとき

  • 物理サーバでDISK容量が足りなくなってくると大変だった。
    • とにかく不要ファイルを削除する
    • ログの保持期間を検討する
    • 外付けハードディスクをつける
    • リプレース
  • AWSだと
    • EBSでDISKの追加と拡張

DISK容量問題もAWSだと簡単に対応可能ですね。

スペックが不足したとき

運用していて、サーバのスペックが足りなくなってくるときってありますよね。

  • 物理サーバだと
    • とにかくミドルウェアのチューニング
    • スペックの高いサーバに移設(時間かかる)
    • 負荷分散(時間かかる)
  • AWSだと
    • スケールアップ(インスタンスタイプ変更)
    • スケールアウト(AMI取得して負荷分散)

スペックが不足してきた時の対応も柔軟にできます。

アクセスが増えたとき

アクセスが増えるって嬉しいことですが、すぐにサーバを用意できない経験をしたこともあると思います。

  • 物理だと
    • 負荷分散するためにサーバを用意
    • サーバスペックあげるためにリプレース
  • AWSだと
    • ELB + EC2 で負荷分散
    • スペックアップ(インスタンスタイプ変更)

負荷分散もスペックアップも即時対応できますね。

バックアップ

バックアップって必要ですよね。

  • 物理だと
    • バックアップサーバを用意
    • rsync, tar, dar, dumpなどのバックアップツールを選定
    • mount, scp, mv, ftpなどのデータ転送方法選定
  • AWSだと
    • スナップショット!

バックアップってrsync, tar, dar, dumpなどのバックアップツールを選定し バックアップサーバにどうやってデータを送るかを考えますがこちらもDISK容量が気になってきたり、 複数のツールを使っていると復旧の手順が煩雑化したりしますが AWSのスナップショットだとS3に保存されるので容量も気にせず、耐久性も心配ありません。 タグをつけて世代管理も簡単にできたり、復旧手順の一元化も可能です。

困った時

AWSサポートが優秀

  • トラブルシューティングをしてくれる
  • ベストプラクティスも教えてくれる
  • サードパーティ製のソフトウェアのサポートも行ってくれる

ビジネス以上のサポートに入ると24時間、電話、メール、チャットでの対応もしてくれてとても安心。

まとめ

昔は物理サーバの環境が多かったので上記のような問題がありましたが AWS環境が増えていくにつれて柔軟・迅速に対応が行えるようになったと思います。 そして、AWSサポートは素晴らしいと思います。

さいごに

入社後初のプレゼンでとても緊張しましたがいい経験になりました。
AWSを使っている方にとっては新しい内容ではありませんでしたが
今後、AWS環境を使用するという選択肢が増えていくのではないでしょうか。