JAWS DAYS 2015 SimpleWorkflowとOpsWorksでサービスを開発して解ったこと
•Transferir como PPTX, PDF•
8 gostaram•5,228 visualizações
JAWS DAYS 2015 (2015/03/22)で発表した資料です。
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (14)
Destaque
Destaque (20)
Semelhante a JAWS DAYS 2015 SimpleWorkflowとOpsWorksでサービスを開発して解ったこと
Semelhante a JAWS DAYS 2015 SimpleWorkflowとOpsWorksでサービスを開発して解ったこと (16)
Mais de Tetsuya Chiba
Último
Último (8)
JAWS DAYS 2015 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シャツ
- 6. CLOUD AUTOMATOR の提供価値 わたしたちは 運用を自動化するサービス を提供します 運用管理 44.9% 保守開発 30.8% 新規開発, 24.3% 出典) 日経BP社 「企業情報システムの運用管理に関する実態調査2013」 運用の自動化
- 9. (クラウドオートメーター)とは、 AWS(Amazon Web Services) の運用を自動化するサービスです。 CLOUD AUTOMATOR とは これまでの AWSオペレーション AWS運用担当者が 手動で対応 新しい AWSオペレーション CLOUD AUTOMATOR で自動運用
- 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 は、運用の自動化を実現するために さまざまな「トリガー」と「アクション」を提供します。
- 19. CLOUD AUTOMATOR の特徴 外部サービスとの連携も 可能なトリガー 多彩なアクション ジョブを自由に組み合わせ 完全自動化 『タイマートリガー』では時間、曜日、日にち を指定することが可能です。 その他にも『HTTPリクエスト』『SQS』等、 様々な条件をトリガーに利用することが可能で す。 『EC2インスタンスを起動』『EC2インスタンス を停止』『EBSボリュームのスナップショットを 作成』『AMIを作成』『RDSのスナップショット を作成』『DNS(Route53)のレコードを更新す る』など、AWSリソースの操作を自動化しま す。 多彩な自動化オプションで、AWSの運用を自動 化する機能を提供します。 『条件（トリガー）』＋『処理（アクショ ン）』を自由に組み合わせて人手に頼っていた タスクを自動化（ジョブ化）します。
- 20. アーキテクチャ全体像
- 22. アーキテクチャ全体像
- 25. SWFの利用イメージ
- 26. SWFの利用イメージ
- 27. SWFの利用イメージ
- 29. 3つの実装パターンを比較 1. フルスクラッチ 2. SQSの利用 3. SimpleWorkflowの利用
- 30. フルスクラッチの場合 • 1回だけジョブを実行する為の設計 • タイムアウト処理の設計 • リトライ処理の設計
- 31. SQSを使った場合
- 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プロセス）
- 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について
- 46. アーキテクチャ全体像
- 48. OpsWorksの利用イメージ
- 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プロセスの停止スクリプトは処 理が終わったプロセスから順次落とす
- 60. OpsWorks 3つの注意点
- 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. さいごに