Transcript

• 1. SimpleWorkflowとOpsWorksで サービスを開発して解ったこと
• 2. •千葉 哲也 • 株式会社サーバーワークス • JAWS UG 横浜支部 •Cloud Automator • http://cloudautomator.com •twitter : @kachina_t •facebook : tetsuya.chiba •好きなAWSサービス • SimpleWorkflow / OpsWorks 自己紹介
• 3. TwitterでJaws Daysに参加しよう！ たくさんリツイートされた人にプレゼント！ @jawsdays 参加方法は簡単！3ステップ @awscloud_jp ＋ #jawsdaysをつけてツイート投稿！ 1番リツイート数を集めた人が 優勝者です！ AWS公式TwitterとJAWS DAYS公式Twitterをフォロー ?? 17:00～の懇親会で優勝者発表です。 ※9:00～16:50のTweetが対象です。 ＋ Kindle JAWS Tシャツ ＋ ウェアラブル Moff Band JAWS Tシャツ Step 1 （参加条件になります） Step 2 Step 3 （Jaws Daysに関する投稿なら何でもOK！） JAWS Tシャツ
• 4. •Cloud Automatorのご紹介 •SimpleWorkflowについて •OpsWorksについて •まとめ もくじ
• 5. CLOUD AUTOMATOR ご紹介 AWSを進化させるオペレーション自動化サービス
• 6. CLOUD AUTOMATOR の提供価値 わたしたちは 運用を自動化するサービス を提供します 運用管理 44.9% 保守開発 30.8% 新規開発, 24.3% 出典) 日経BP社 「企業情報システムの運用管理に関する実態調査2013」 運用の自動化
• 7. •2010年03月サービスイン • AWSマネジメントコンソールの日本語化 について [AWSマネジメントコンソール] [Cloudworksコンソール] 前身の
• 8. 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ボリューム [操作系機能の利用数] [自動化系機能の利用数]
• 9. (クラウドオートメーター)とは、 AWS(Amazon Web Services) の運用を自動化するサービスです。 CLOUD AUTOMATOR とは これまでの AWSオペレーション AWS運用担当者が 手動で対応 新しい AWSオペレーション CLOUD AUTOMATOR で自動運用
• 10. CLOUD AUTOMATOR でできること 業務時間外は開発用インスタンスを 停止してコストを削減したい ローカルディスクのスナップショッ トを毎週取得したい EC2インスタンスのAMIを毎日取得 したい RDSインスタンスのスナップショッ トを毎日取得したい 指定の日時になったらDNSレコード を書き換えて新デザインのサイトを 公開したい 1 2 3 4 5 AWSの運用に欠かせない 様々なオペレーションを 自動化します。
• 11. 1. 業務時間外は開発用インスタンスを停止してコストを削減したい
• 12. 1. 業務時間外は開発用インスタンスを停止してコストを削減したい
• 13. 1. 業務時間外は開発用インスタンスを停止してコストを削減したい
• 14. 1. 業務時間外は開発用インスタンスを停止してコストを削減したい
• 15. 1. 業務時間外は開発用インスタンスを停止してコストを削減したい
• 16. CLOUD AUTOMATORを利用すれば 「トリガー」と「アクション」を定義して 自動的な運用が実現できます。 CLOUD AUTOMATOR 実現例 業務時間外は開発用インスタンスを停止し てコストを削減したい 時刻指定(毎日) EC2インスタンスを起動/終了 ローカルディスクのスナップショットを毎 週取得したい 曜日指定(毎週) EBSボリュームのスナップショットを作成 EC2インスタンスのAMIを毎日取得したい 時刻指定(毎日) AMIを作成 RDSインスタンスのスナップショットを毎 日取得したい 時刻指定(毎日) RDSのスナップショットを作成 指定の日時になったらDNSレコードを書き 換えて新デザインのサイトを公開したい 時刻指定(一度だけ) DNS(Route53のレコードを更新 1 2 3 4 5
• 17. CLOUD AUTOMATOR のフィーチャー トリガー アクション 日時指定(一度だけ) 時刻指定(毎日) 曜日指定(毎週) 日にち指定(毎月) SQSメッセージ受信 SNSメッセージ受信 HTTPリクエスト EC2インスタンスを起動 EC2インスタンスを停止 EBSのスナップショットを作成 AMIを作成 AMIをリージョン間コピー RDSのスナップショットを作成 DNSのレコードを変更 ※ 今後対応の予定 Disaster Recovery Redshiftクラスタの削除 Redshiftスナップショットのリストア CLOUD AUTOMATOR は、運用の自動化を実現するために さまざまな「トリガー」と「アクション」を提供します。
• 18. • SQSを通じて連携することで、外部サービスとCloud Automatorのジョブ とをシームレスに結合可能 外部サービスとの連携
• 19. CLOUD AUTOMATOR の特徴 外部サービスとの連携も 可能なトリガー 多彩なアクション ジョブを自由に組み合わせ 完全自動化 『タイマートリガー』では時間、曜日、日にち を指定することが可能です。 その他にも『HTTPリクエスト』『SQS』等、 様々な条件をトリガーに利用することが可能で す。 『EC2インスタンスを起動』『EC2インスタンス を停止』『EBSボリュームのスナップショットを 作成』『AMIを作成』『RDSのスナップショット を作成』『DNS(Route53)のレコードを更新す る』など、AWSリソースの操作を自動化しま す。 多彩な自動化オプションで、AWSの運用を自動 化する機能を提供します。 『条件（トリガー）』＋『処理（アクショ ン）』を自由に組み合わせて人手に頼っていた タスクを自動化（ジョブ化）します。
• 20. アーキテクチャ全体像
• 21. アーキテクチャ全体像 Worker App Rails App
• 22. アーキテクチャ全体像
• 23. SimpleWorkflowについて
• 24. SimpleWorkflow とは •開発者が並行したステップまたは連続したステッ プがあるバックグラウンドジョブを構築、実行、 拡張する為のサービスです •完全マネージド型の状態トラッカー、およびタス クコーディネーター
• 25. SWFの利用イメージ
• 26. SWFの利用イメージ
• 27. SWFの利用イメージ
• 28. なぜSimpleWorkflowを 選んだのか？
• 29. 3つの実装パターンを比較 1. フルスクラッチ 2. SQSの利用 3. SimpleWorkflowの利用
• 30. フルスクラッチの場合 • 1回だけジョブを実行する為の設計 • タイムアウト処理の設計 • リトライ処理の設計
• 31. SQSを使った場合
• 32. SQSを使った場合 • ジョブ毎にWorkerを専有するので、事前に同時刻 に実行されるジョブの数だけWorkerプロセスを準 備しておく必要がある
• 33. SQSを使った場合 • 複数のWorkerが同じメッセージを受け取る可能性 がある SQS【最低1度のメッセージ到達を保証】
• 34. SimpleWorkflowを使った場合
• 35. SimpleWorkflowを選んだ理由 • タイマー処理はSWFにおまかせ • 設定した日時に1度だけWorkflowを実行することを保証 してくれます • 『日時』ではなく『n秒後に再開』と指定するので 『作成したAMIが完了ステータスになるまで5秒毎に確 認』の様な処理も簡単に実現
• 36. SimpleWorkflowを選んだ理由 • タイムアウト、リトライ処理もSWFにおまかせ • Activity毎にタイムアウトを設定 • 正常動作しているWorkerでリトライ • Workflowの状態はSWF側に保持しているのでWorker プロセスだダウンしても再開可能
• 37. SimpleWorkflowを選んだ理由 • Sleep処理もSWFにおまかせ • 『作成したAMIが完了ステータスになるまで5秒毎に確 認』の様な処理はSWFに一旦返して、その間に別の仕事 ができます （1ジョブ ≠ 1プロセス）
• 38. SimpleWorkflowの良いところ •スケジュールした時間にWorkflowを1度だけ実行す ることについてSWFが保証してくれます •Workflowの状態はSWFに保持されます • Workerプロセスが異常終了した際にもリトライする機能 が用意されている • 最大で1年間ワークフローの実行を試し続ける •小さくActivityを設計することでWorker側のリソー スを最適化 •OpsWorksと併用することで高い可用性を実現
• 39. SimpleWorkflow 3つの注意点
• 40. 【注意-1】デバッグ超タイヘン •SimpleWorkflow、あまりシンプルではありません •2回実行されても問題なければSQSがおすすめ
• 41. 【注意-2】Workflow Execution Historyに持たせ る情報は小さく •Workflow Execution Historyとは『ワークフローの状 態』の事を指します •SWFからタスクを受け取る度に再現(replay)します サイズが大きくなる ＝ 処理開始までのオーバーヘッド タイムアウト → リトライ → タイムアウト → リトライ…
• 42. 【注意-3】Loop処理について •Workflow Execution Historyの上限回数は25,000 •上記の様なステータスをチェックする様な処理を 実装する際には • リトライの間隔を指数関数的に増加させる (1, 2, 4, 8, 16…) • リトライの回数に上限を設ける
• 43. OpsWorksについて
• 44. OpsWorks とは •アプリケーションを容易にデプロイおよび操作で きるアプリケーション管理サービス •パッケージのインストール、ソフトウェア設定お よびストレージなどのリソースを含む、各コン ポーネントのアプリケーションのアーキテクチャ および仕様を定義できます
• 45. アーキテクチャ全体像 Worker App Rails App
• 46. アーキテクチャ全体像
• 47. なぜOpsWorksを 選んだのか？
• 48. OpsWorksの利用イメージ
• 49. OpsWorksの利用イメージ OpsWorksから参照
• 50. OpsWorksの利用イメージ デプロイ
• 51. OpsWorksの利用イメージ Chefを使って構成管 理
• 52. OpsWorksの利用イメージ （Dev, Staging, QA環境） テストが通ったら 自動デプロイ
• 53. モニタリング •標準でCloudWatchでCPU / メモリ / ロードアベレー ジ / プロセス数を監視 •レイヤ毎の平均負荷状況も提供
• 54. オートスケール機能 •時間ベースのオートスケール • 殆どのジョブが深夜帯に実行されている 0 2 4 6 8 10 12 14 16 18 20 22 Starter 4台 2台 Business 6台 4台 Enterprise 8台 6台 4台 •ロードベースのオートスケール • インスタンス群(レイヤ)の平均負荷状況に応じてインス タンスの増減
• 55. 権限管理 •IAMユーザー毎に権限を設定 • Stackの参照権限 • Stackへのデプロイのみ • フル権限 •OSのユーザーを自動作成 • ec2-userを共有しない • IAMユーザー毎にアカウントを発行 • ssh接続を許可するか？ • sudo権限を付与するか？
• 56. Tips
• 57. EC2インスタンスの起動・停止 •EC2インスタンスへのSSH接続はしない 設計 •プロセスは自動起動 / 停止 •Workflow Worker •Activity Worker •Workerプロセスの停止スクリプトは処 理が終わったプロセスから順次落とす
• 58. WorkerプロセスはMONITで監視
• 59. 例外の通知には外部サービスを利用 予期せぬ例外
• 60. OpsWorks 3つの注意点
• 61. 【注意-1】Auto Healing機能について •EC2インスタンスのH/W障害でAuto Healingが発生 •別のEC2インスタンスに変わるので以前のログが消 える
• 62. OpsWorksの利用イメージ ログの集約
• 63. 【注意-1】Auto Healing機能について •EC2インスタンスのH/W障害でAuto Healingが発生 •別のEC2インスタンスに変わるので以前のログが消 える ログ管理サービスを利用しよう CloudWatch Logs / Papertrail / Logentries …
• 64. 【注意-2】Root Volumeサイズ •OpsWorksから起動されるEC2インスタンスはデフォ ルトが8GB •Root Volumeのサイズ変更はできないので必要に応 じてEBSを追加する • Custom Cookbookでマウント • パーミッションの変更
• 65. 【注意-2】Root Volumeサイズ •OpsWorksから起動されるEC2インスタンスはデフォ ルトが8GB •Root Volumeのサイズ変更はできないので必要に応 じてEBSを追加する • Custom Cookbookでマウント • パーミッションの変更 Logrotateの設定は『日数』ではなく 『ファイルサイズ』でローテーションする
• 66. 【注意-3】Rubyのバージョン変更 • 2014/12/01 aws/opsworks-cookbooksのRuby 2.1系デフォルトバージョン が2.1.5に変更されていた • 開発環境のEC2インスタンスを追加した際に Rubyが2.1.5で起動されたのでWorkerアプリが正常に動作しない
• 67. 【注意-3】Rubyのバージョン変更 • 2014/12/01 aws/opsworks-cookbooksのRuby 2.1系デフォルトバージョン が2.1.5に変更されていた • 開発環境のEC2インスタンスを追加した際に Rubyが2.1.5で起動されたのでWorkerアプリが正常に動作しない Custom CookbookでRubyのバージョンを固定
• 68. まとめ
• 69. SimpleWorkflow •複雑なサービスです • SQSで解決できる課題じゃないか、もう一度考えてみま しょう •1つのActivityは小さく設計しよう •Sleep処理はSWF側に任せよう •Workflow Execution Historyに持たせるデータは少な く •ステータスチェック等の繰り返し間隔には指数関 数的に増加させる
• 70. OwsWorks •ssh接続しない運用設計 • Workerプロセスの自動起動、停止 • Workerプロセスの自動復旧（MONIT） •オートスケール機能を使う • 時間ベース / ロードベース •Auto Healing機能は有効可 •ログはログ管理サービスに集約 •Logrotateはファイルサイズでローテーション設定
• 71. さいごに
• 72. クラウドで、世界を、もっと、はたらきやすく