1. AWSを活用して少人数で
複数のサービスを運用するコツ
株式会社 ソニックガーデン
安達 輝雄

2. 自己紹介
@interu 安達輝雄
アプリケーションの開発
＋
インフラの構築/運用
http://interu.hatenablog.com
開発しているサービス

3. SonicGarden
エンジニア：5名

4. 開発/運用サービス一覧
自社サービス
パートナーシップモデル
・データ販売サイト ・植物栽培キッド販売サイト
・ドキュメント配信 ・SEO関連サービス
・Flash動画生成サービス ・・・etc

5. いくつものサービスを
たった5人のエンジニアで
どうやって
開発 / 運用 してる？

6. Answer.
DevOps
and
AWS/Heroku
and
自動化/共通化/効率化

7. 利用比率
：
5 ： 5

8. 今日は
JAWS-UG。
Herokuの話は
すべて割愛！

9. そろそろ本題に
SonicGardenは
サービス運用について
どのように考えているか？

10. SonicGardenのMission
開発 > 運用

11. SonicGarden流
サービス運用ポリシー
構築/運用コストは抑えつつ
安定したサービスを提供する

12. 運用コストを
どのように抑える？

13. 構築/運用コストを抑える
航空業界の
LCC的発想

14. 構築/運用コストを抑える
LCC
● 機体を1つのシリーズに統一
● 研修/教育コストを抑えれる
● パイロットなら誰でも運転できる
※ 機体毎に免許取得が義務付けられている
● システムの自動化
● チェックイン等を全てシステム化
● 通常フローで人を介すサービスをしない

15. 構築/運用コストを抑える
SonicGarden
● OS/ディストロを統一
- ミドルウェア導入/設定
- セキュリティ設定
など基本設定を行ったテンプレートAMIを
作成し、アプリのみを入れ替えてサービス
構築/運用コストの削減

16. 安定したサービスの提供
SonicGarden
● システムの自動化
- EBSスナップショットの取得
- 実データをS3にバックアップ
- AMIの定期作成 ...etc
安定した品質を全サービスで提供

17. LCC的発想以外にも...

18. 新しいディストロの採用
2年で全乗り換え
● 新しいパッケージを利用可能
● アプリケーションF/Wに追従しやすい
● パッケージがメンテされている
● Security Fix / Bug Fixをすぐに適用できる
運用コストを削減

19. ディストロの
置き換えは大変では？

20. Railsのバージョンアップに伴い
APサーバを新しいディストロに
切り替え
Ruby 1.8.7 ⇛ 1.9.3

21. リプレースまでの過程
(0)新環境構築 EC2の活用
(1)新環境単体でテスト
EBSの活用
(2)新環境に本番データを利用して動作確認
(3)新環境を本番DBに接続し限定ユーザで試用
(4)新環境を本番環境に切り替え

22. リプレースまでの過程
(0)新環境構築
(1)新環境単体でテスト
(2)新環境に本番データを利用して動作確認
(3)新環境を本番DBに接続し限定ユーザで試用
(4)新環境を本番環境に切り替え

23. リプレースまでの過程
(0)新環境構築
(1)新環境単体でテスト
(2)新環境に本番データを利用して動作確認
(3)新環境を本番DBに接続し限定ユーザで試用
(4)新環境を本番環境に切り替え
ELB/Route53/Elastic IPの活用

24. その他、
効率化を目的に
いくつか取り組んで
いることを紹介

25. ① バックアップ

26. ① バックアップ
データ/ログのバックアップを
取得するのは当たりまえ
バックアップ処理中のエラー
検出も当たりまえ

27. ① バックアップ
本当にバックアップを
取得できてる？？

28. ① バックアップ
バックアップしたものが
存在するかを確認する方が確実
だけど・・・
複数サービスを運用していると
全てを確認するのは一苦労

29. ① バックアップ
AWS Backup Checker
指定した期間内のバックアップが存在するかを
AWSのAPIを利用してチェック
- EBS snapshot
- S3
- AMI

31. アプリケーションログ、システムログ、アプリケーションデータ
データディスクのスナップショット

32. Coming Soon.

33. ② AWS障害対策

34. AWSは障害が少なくて
非常に助かってます！
が、
障害を0にはできないのが現実

35. 過去に遭遇した大規模障害
● 2011年4月
us-eastでEBS障害
http://interu.hatenablog.com/entry/20110425/1303731515
● 2012年6月
us-eastで電源障害・API障害

36. 障害からの学び
EBS障害が発生すると
● EBS bootのAMIは起動不可
● EBS上のデータへのアクセス不可

37. 障害からの学び
● Instance storeタイプのAMIを
別Regionに作成しておく
● データも別RegionのS3にバックアップ
⇛ DR対策できあがり

38. で、何を効率化したの？

39. ● 定期EBS snapshot取得スクリプト
● EBS boot型AMI作成スクリプト
● Instance store型AMIを別Regionに
作成するスクリプト ※要AKIの準備
https://github.com/interu/management_utilities

40. Fin.