安心してぐっすり眠るための AWS 運用術

安心してぐっすり眠るための 
AWS 運用術
シナジーマーケティング株式会社坂井学 
2015/10/31 Innovation EGG 第 5 回

自己紹介
‣ 坂井学（さかいまなぶ）
‣ シナジーマーケティング株式会社所属
‣ アプリケーション開発、インフラ設計、運用など 
ひと通り担当

システムが正常に稼動し続け
られるような状態を維持する
こと

理想的な運用 😄
‣ システムが安定稼働している
‣ 障害の芽を早めに取り除けている
‣ 継続的な改善ができている（ex. 自動化）
‣ 早く帰れている
‣ ユーザーやお客様が喜んでくれている

実際の運用 😱
‣ 夜間や休日に限って障害が起きる
‣ 行き当たりばったりで障害対応にあたる
‣ 障害対応に追われて本来の仕事が進まない
‣ 新しい技術を試す余裕がない
‣ 挙げればキリがない……

https://www.ﬂickr.com/photos/nate/321938695/

少人数でAWSを運用する
ために意識していること

紹介するサービス
‣ BtoB 向けの CRM サービス
‣ SaaS 型の Web サービス
‣ 言語は Scala + Play Framework
‣ データベースは HBase + PostgreSQL
‣ チームは 4 人、開発から運用まで一気通貫で行う

Full AWS, No On-premises
‣ VPC
‣ EC2
‣ ELB
‣ Auto Scaling
‣ Route 53
‣ RDS
‣ EMR
‣ S3, Glacier
‣ SES
‣ CloudWatch

障害を避ける最もよい方法は、 
常に障害を起こすことである

発想を変えよう
‣ 障害は非日常ではなく、常に起きるという前提に立つ
‣ オンプレの常識は捨ててクラウドネイティブな発想に
切り替える
‣ 理想は「人が運用しなくてもいい」状態

フルマネージドサービス
‣ ELB, RDS, EMR, SES, Route 53 などを採用
‣ オンプレより自由度は減るが制約は強みになる
‣ AWS のフルマネージドを徹底的に使いこなすこと

実際どうなったか？
‣ 運用にかかる工数が 75% 減
‣ 制約を受け入れることでシンプルな構成に進化
‣ ハードウェア障害と無縁に（詳細は次ページ）

Immutable Infrastructure
‣ サーバは状態を持たず、いつでも破棄できる状態
‣ 一度起動したサーバに変更は加えない
‣ EC2 のハードウェア障害に遭遇しても、新しいインス
タンスを起動すれば OK

‣ リリース時はサーバを丸ごと入れ替えるので、複雑な
手順が不要に（リリース職人の排除）
‣ SSH でログインすることも滅多になくなった
‣ サーバ障害が起きてもすぐに復旧できるという大きな
安心感

‣ ワークロードに応じてサーバ台数を自在に増減
‣ 対応するにはアプリケーションの改修も必要で手間が
かかるが、長い目で見れば安定運用に絶大な効果
Auto Scaling

‣ 突発的な負荷を恐ることがなくなった
‣ バックエンドのサーバは 0 台までスケールインするの
で夜間や休日分の無駄なコストが減らせた
‣ 1 台の起動時間はごくごく短いので、そもそも運用す
るがない

まだまだ改善中
‣ 一部の機能に Lambda を採用しサーバレスを実験中
‣ HBase からフルマネージドの Redshift へ移行予定
‣ 手作業が残ってる箇所の見直し

改善を重ねた結果
‣ 夜中にアラートメールで起こされることは皆無
‣ アプリケーション開発により工数を割けるように
‣ 守りから攻めの運用に変化
‣ 気になるサービス稼働率も……

https://www.ﬂickr.com/photos/mrezafaisal/6268129336/
99.9942％
2014年下半期のサービス稼働率

まとめ
‣ AWS をうまく使いこなせば運用は確実に楽になる
➡ フルマネージドサービスを積極的に使う
➡ 障害は常に起きるという前提の設計
‣ クラウドにはクラウドの考え方がある
‣ 「人が運用しなくてもいい」状態を目指す

https://www.ﬂickr.com/photos/40032755@N06/4862205105/
Thank you! 😊

Recommended