2015年3月26日に開催された『AWSプロダクトシリーズ｜よくわかるAWS OpsWorks』で発表した資料です。 http://kokucheese.com/event/index/270160/

1. SimpleWorkflowとOpsWorksで
サービスを構築して解ったこと
2015年3月26日
株式会社サーバーワークス
サービス開発部 千葉 哲也

2. • Cloud Automator
• Cloud Automatorとは
• アーキテクチャについて
• OpsWorksについて
• なぜOpsWorksを選んだのか
• Tips
• 3つの注意点
•まとめ
もくじ

3. CLOUD AUTOMATOR の提供価値
わたしたちは
運用を自動化するサービス
を提供します
運用管理
44.9%
保守開発
30.8%
新規開発,
24.3%
出典) 日経BP社 「企業情報システムの運用管理に関する実態調査2013」
運用の自動化

4. •2010年03月サービスイン
• AWSマネジメントコンソールの日本語化
について
[AWSマネジメントコンソール]
[Cloudworksコンソール]
前身の

5. create_image
create_rds_snapshot
create_snapshot
request_volume_copy
start_instance
stop_instance
201004
201005
201006
201007
201008
201009
201010
201011
201012
201101
201102
201103
201104
201105
201106
201107
201108
201109
201110
201111
201112
201201
201202
201203
201204
201205
201206
201207
201208
201209
201210
201211
201212
201301
201302
201303
201304
201305
201306
201307
201308
201309
201310
201311
インスタンス操作
EIP
キーペア
ロードバランサー
セキュリティグループ
スナップショット
EBSボリューム
[操作系機能の利用数]
[自動化系機能の利用数]

6. (クラウドオートメーター)とは、
AWS(Amazon Web Services) の運用を自動化するサービスです。
Cloud Automator とは
これまでの
AWSオペレーション
AWS運用担当者が
手動で対応
新しい
AWSオペレーション
CLOUD AUTOMATOR
で自動運用

7. Cloud Automator でできること
業務時間外は開発用インスタンスを
停止してコストを削減したい
EC2インスタンスのAMIを毎日取得
したい
RDSインスタンスのスナップショッ
トを毎日取得したい
設定料金を超えたら開発用のEC2イ
ンスタンスを停止したい
指定の日時になったらDNSレコード
を書き換えて新デザインのサイトを
公開したい
1
2
3
4
5
AWSの運用に欠かせない
様々なオペレーションを
自動化します。

8. CLOUD AUTOMATOR のフィーチャー
トリガー アクション
日時指定(一度だけ)
時刻指定(毎日)
曜日指定(毎週)
日にち指定(毎月)
SQSメッセージ受信
SNSメッセージ受信
HTTPリクエスト
EC2インスタンスを起動
EC2インスタンスを停止
EBSのスナップショットを作成
AMIを作成
AMIをリージョン間コピー
RDSのスナップショットを作成
DNSのレコードを変更
※ 今後対応の予定 Disaster Recovery
Redshiftクラスタの削除
Redshiftスナップショットのリストア
CLOUD AUTOMATOR は、運用の自動化を実現するために
さまざまな「トリガー」と「アクション」を提供します。

9. Cloud Automatorを利用すれば
「トリガー」と「アクション」を定義して
自動的な運用が実現できます。
Cloud Automator 実現例
業務時間外は開発用インスタンスを停止し
てコストを削減したい
時刻指定(毎日) EC2インスタンスを起動/停止
EC2インスタンスのAMIを毎日取得したい
曜日指定(毎週) AMIを作成
RDSインスタンスのスナップショットを毎
日取得したい
時刻指定(毎日) RDSのスナップショットを作成
設定料金を超えたら開発用のEC2インスタ
ンスを停止したい
SNS EC2インスタンスを停止
指定の日時になったらDNSレコードを書き
換えて新デザインのサイトを公開したい
時刻指定(一度だけ) DNS(Route53のレコードを更新
1
2
3
4
5

10. ジョブ実行後の処理
•メールレポート
• アカウントに設定したメールアドレスに送信
• 成功時、失敗時、両方を選択出来ます
•SQS
• ご指定のSQSにメッセージを送信
• 成功時、失敗時、両方を選択出来ます

11. • SQSを通じて連携することで、外部サービスとCloud Automatorのジョブ
とをシームレスに結合可能
障害の検知
EC2インスタンス
を起動
DNSレコード
の変更
ジョブ終了
HTTP
トリガー
外部サービス + Cloud Automator
SQS
トリガー
メール

12. 外部サービスとの連携も
可能なトリガー
多彩なアクション ジョブを自由に組み合わせ
完全自動化
『タイマートリガー』では時間、曜日、日にち
を指定することが可能です。
その他にも『HTTPリクエスト』『SQS』等、
様々な条件をトリガーに利用することが可能で
す。
『EC2インスタンスを起動』『EC2インスタンス
を停止』『EBSボリュームのスナップショットを
作成』『AMIを作成』『RDSのスナップショット
を作成』『DNS(Route53)のレコードを更新す
る』など、AWSリソースの操作を自動化しま
す。
多彩な自動化オプションで、AWSの運用を自動
化する機能を提供します。
『条件（トリガー）』＋『処理（アクショ
ン）』を自由に組み合わせて人手に頼っていた
タスクを自動化（ジョブ化）します。
Cloud Automator の特徴

13. EC2の自動停止/起動

14. 業務時間外は開発用インスタンスを停止してコストを削減したい

15. 業務時間外は開発用インスタンスを停止してコストを削減したい

16. 業務時間外は開発用インスタンスを停止してコストを削減したい

17. 業務時間外は開発用インスタンスを停止してコストを削減したい

18. アーキテクチャ全体像

19. アーキテクチャ全体像
Worker App
Rails App

20. アーキテクチャ全体像

21. OpsWorksについて

22. OpsWorks とは
•アプリケーションを容易にデプロイおよび操作で
きるアプリケーション管理サービス
•パッケージのインストール、ソフトウェア設定お
よびストレージなどのリソースを含む、各コン
ポーネントのアプリケーションのアーキテクチャ
および仕様を定義できます

23. アーキテクチャ全体像
Worker App
Rails App

24. アーキテクチャ全体像

25. なぜOpsWorksを
選んだのか？

26. OpsWorksの利用イメージ

27. OpsWorksの利用イメージ
OpsWorksから参照

28. OpsWorksの利用イメージ
デプロイ

29. OpsWorksの利用イメージ
Chefを使って構成管
理

30. OpsWorksの利用イメージ
（Dev, Staging, QA環境）
テストが通ったら
自動デプロイ

31. モニタリング
•標準でCloudWatchでCPU / メモリ / ロードアベレー
ジ / プロセス数を監視
•レイヤ毎の平均負荷状況も提供

32. オートスケール機能
•時間ベースのオートスケール
• 多くのジョブが実行される深夜帯だけインスタンスを追
加
0 2 4 6 8 10 12 14 16 18 20 22
Starter 4台 2台
Business 6台 4台
Enterprise 8台 6台
•ロードベースのオートスケール
• インスタンス群(レイヤ)の平均負荷状況に応じてインス
タンスの増減

33. 権限管理
•IAMユーザー毎に権限を設定
• Stackの参照権限
• Stackへのデプロイのみ
• フル権限
•OSのユーザーを自動作成
• ec2-userを共有しない
• IAMユーザー毎にアカウントを発行
• ssh接続を許可するか？
• sudo権限を付与するか？

34. Tips
EC2インスタンスへSSHしない運用設計

35. EC2インスタンスの起動・停止
•Workerプロセスは自動起動 / 停止
•Workerプロセスの停止スクリプトは処
理が終わったプロセスから順次落とす

36. WorkerプロセスはMONITで監視

37. OpsWorks
3つの注意点

38. 【注意-1】Auto Healing機能について
•EC2インスタンスのH/W障害でAuto Healingが発生
•別のEC2インスタンスに変わるので以前のログが残
らない

39. OpsWorksの利用イメージ
ログの集約

40. 例外の通知には外部サービスを利用
予期せぬ例外

41. 【注意-1】Auto Healing機能について
•EC2インスタンスのH/W障害でAuto Healingが発生
•別のEC2インスタンスに変わるので以前のログが残
らない
ログ管理サービスを利用しよう
CloudWatch Logs / Papertrail / Logentries …
例外通知サービスを利用しよう
Airbrake / Errbit …

42. 【注意-2】Root Volumeサイズ
•OpsWorksから起動されるEC2インスタンスはデフォ
ルトが8GB
•Root Volumeのサイズ変更はできないので必要に応
じてEBSを追加する
• Custom Cookbookでマウント
• パーミッションの変更

43. 【注意-2】Root Volumeサイズ
•OpsWorksから起動されるEC2インスタンスはデフォ
ルトが8GB
•Root Volumeのサイズ変更はできないので必要に応
じてEBSを追加する
• Custom Cookbookでマウント
• パーミッションの変更
Logrotateの設定は『日数』ではなく
『ファイルサイズ』でローテーションする

44. 【注意-3】Rubyのバージョン変更
• 2014/12/01
aws/opsworks-cookbooksのRuby 2.1系デフォルトバージョン
が2.1.5に変更されていた
• 開発環境のEC2インスタンスを追加した際に
Rubyが2.1.5で起動されたのでWorkerアプリが正常に動作しない

45. 【注意-3】Rubyのバージョン変更
• 2014/12/01
aws/opsworks-cookbooksのRuby 2.1系デフォルトバージョン
が2.1.5に変更されていた
• 開発環境のEC2インスタンスを追加した際に
Rubyが2.1.5で起動されたのでWorkerアプリが正常に動作しない
Custom CookbookでRubyのバージョンを固定

46. まとめ

47. OwsWorks
• ssh接続しない運用設計
• Workerプロセスの自動起動、停止
• Workerプロセスの自動復旧（MONIT）
• オートスケール機能を使う
• 時間ベース / ロードベース
• Auto Healing機能は有効可
• ログ、例外は外部サービスに出力
• CloudWatch Logs / Papertrail / Logentries
• Airbrake / Errbit
• Logrotateはファイルサイズでローテーション設定

48. クラウドで、世界を、もっと、はたらきやすく