(Google+)100100件のシェア(ちょっぴり話題の記事)この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。訓練されたアップル信者、都元です。ここまで「AWSでジョブWorkerを構成するベストプラクティス」と題して2本の記事を書いてまいりました。SQSの巻では、バックグラウンドジョブの実行にはSQSを使ってスケーラビリティを確保しようという、下図中の中段の話をしました。tierの巻では、Workerの実装方法として、図中の下段の話をしました。今回は、上段の話です。ジョブスケジューリングここまでの話では「ジョブは、ユーザからのWebサーバへのリクエストに伴って発生する」という暗黙の前提で進めてきました。具体的には動画のエンコーディングや、少々時間の掛かる集計処理等をイメージして頂いたと思います。ジョブというのは「ユーザのリクエスト」に起因して発生するばかりではありません。ユーザからのリクエストに関わらず「定期的な繰り返し」という、スケジュールに基づいた発生があります。日次・月次等の自動集計処理や、定時連絡的なメール送信等が考えられます。このようなジョブで皆さんが真っ先に思い浮かべるのがcronでしょう。直感に従って、cronで10分に一度、SQSにメッセージを送るトリガサーバを思い浮かべてください。トリガサーバの冗長化ところで、クラウドの売りの一つは「スケーラビリティ(拡張性)」です。これは単純に、HTTPリクエスト処理要求の増加に伴ってWebサーバの数を増やすだけの話ではありません。昨日ご紹介したように、ロードバランサ、キュー、ワーカー、そして(RDSであれば限定的ですが)データベースのように、システム内の各コンポーネントについて、スケールアウトできる構成が期待されます。「アベイラビリティ(可用性)」の確保のために、各コンポーネントはAZをまたいで冗長化される必要があります。このcronによるトリガの仕組みは「スケーラビリティ(拡張性)」面において、どうでしょうか。仮にトリガの数と頻度が爆発的に増加しても、スケールアウトによる性能の確保は可能でしょうか。1つ1つのcronの処理は小さな負荷ですので、複数のトリガサーバで分担すればどうにかなるかもしれません。要するにシャーディングのようなことをするわけですから、簡単にスケールアウトするとは言い切りづらいところがあります。トリガの発火なんて大した負荷ではありませんので、スケーリングが追いつかない程の大量発火はあまり想像できないので、とりあえず良しとしましょう。「アベイラビリティ(可用性)」面についてはどうでしょうか。冗長性の確保のため、同じトリガサーバを2つ作った途端、トリガの発火も二重化されることになります。SQSの特性上、同じジョブが複数回発火されても良いような作りにしなければならない、というのは以前お話しした通りですが...。それにしてもほぼ必ず2回以上のメッセージが飛んでくる、というのはコレジャナイ感が激しいのではないでしょうか。以上より、私的には「AWSネイティブな設計を前提にする場合、cronは選択肢から外れる」という結論になりました。使うなってことじゃないんですけど、残念な制限事項が残っちゃうことを受け入れる必要がありますね。AWS上のトリガとして望まれるものではこのようなジョブスケジューリングをAWSネイティブに実装する場合、どうすれば良いのでしょうか。私は「AWSがサービスとして提供してくれる」のが一番良いと考えていますが、残念ながら本稿執筆時点で、このようなサービスはありません。Schedulerとかがあればなー。Topicにメッセージを投げてくれるだけでいいんですけど...。AWSさん、ご検討よろしくお願いします。Brianまぁ、無い物ねだりを続けても進歩が無いので。Brianと呼んでください。構成図だけでは伝わりにくいと思うのですがとりあえず。複数のAZにまたがって、複数のEC2インスタンスが起動しています。これらのなかではジョブスケジューラが動いています。これらはトリガサーバです。同じトリガが複数台によって発火されてしまわないよう、RDSを介して同期を行っています。発火予定時刻の数秒前に、各トリガサーバが早い者勝ちで発火の担当決めを行います。トリガ発火のタイミングで、SNSにメッセージを投げるようになっています。その先にSQSをつないでおけば、ジョブWorkerまでの道はひらけますね。APIがありますので、そこを叩くことによって実現します。トリガ情報はRDSに書き込まれるため、複数台ある中の何れか1つのAPIさえ叩ければ登録は完了します。いうわけで、InternalのELB(VPC内からしか叩けないELB)を介して操作します。偉そうに説明してみましたが、この仕組みはJavaのオープンソースライブラリQuartzを使って実装しています。APIでラップし、トリガの発火時の処理としてSNSへのメッセージ送信を実装しただけです。詳細はQuartzのドキュメントを御覧ください(丸投げ)。やってみようここではまず、ざっとポイントを抑えましょう。細かくは色々あるので、実際にBrianを本格的に使ってみようとする際には、次節の詳細仕様をきちんと押さえておいてください。BrianはJava7で実装されたWebアプリケーションです。warファイルはS3に置いてあります。動かすことを前提に考えられています。その他環境で動かすことももちろんできますが、色々メンドクサイと思います。前述の通り、ELBはInternalにします。Brianには認証機構が何もないので、外部公開するのは危険です。ヘルスチェックのエンドポイントは/healthcheckです。BrianはSNSにメッセージをpublishします。Topicが必要です。作っておいて、そのARNを控えておいてください。Profile経由で取得します。Profileが必要です。PowerUserでも良いですし、下記のとおり、きっちり締めあげても構いません。Resourceの項には、先ほど控えたARNを記述します。]}その他、前述の通り、同期用のMySQLが必要なので、RDSで構築する必要があります。BRIAN_TOPIC_ARNの4つの値が必要です。素で聞くと嫌になるもんですよね。いう時のためのCloudFormationです。brianのデモを起動パラメータは以下のとおりです。EC2へのSSH接続用。Brianのバージョンです。あとはデフォルトのままでContinueボタン連打で構いません。環境内にbastion(踏み台)が立ち上がりますので、まずはそこにSSH接続します。続いて、bastionのhome直下に、下記のようなJSONファイルを作って、testEvery20sec.jsonとして保存してください。Consoleを覗いて、ステータスがGreenであることを確認しつつ、beanstalkのURLをひかえておきます。そのURLを使って、下記のようなコマンドを叩くことによってトリガの登録ができます。上記のJSONをPOSTしているだけですね。[/text]JSONでtestEvery20secというトリガ名を指定しています。(世界標準時解釈で)20秒に一度発火するトリガーを定義しています。レスポンスとして、次回の発火予定時刻が返っているのが分かると思います。このPOSTを行った結果、SNSトピックを介して、SQSキューにみるみるメッセージが溜まっていくのが観察できると思います。興味のある方はSNSトピックをemailでsubscribeしてみると、20秒に1回メールが届いて楽しいです。SQSまで届いたメッセージの一つを抜粋・整形して下記に引用しておきます。Formatに定義されたものです。電子署名により、正規のルートから配信されたメッセージであるかどうか検証することも可能です。Messageの値として入れ子のJSONが入っているのでちょっと見づらいのですが。こちらを整形してみると下記の通りです。}}fireTimeは実際の発火時刻、scheduledFireTimeは本来発火予定だった時刻、です。僅かなズレがありますが、分散型である以上許容せざるを得ない誤差です。jobDataの値としては、トリガ作成時に登録したパラメータがそのまま送られてきています。任意のデータを設定して、好きに使って良い部分です。まとめジョブスケジューラは、AWS上でHA実装が難しい仕組みでした。この仕組みを導入することにより、高い信頼性を持ったジョブスケジューラを容易に構築できます。いうわけで、あらためまして、ジョブWorker三部作はこれにて完結です。いので付録だと思ってください。本気で使う人用の情報です。ロケーションアプリケーション自体はcm-public-eb-applicationsバケットのbrian/brian-0.5.warに公開状態で配置してあります。デモ起動用のCloudFormationテンプレートの内容もあわせてご確認ください。起動時のシステムプロパティBrianは、動作に必要なパラメータをシステムプロパティとして受け取ります。Profileを利用。利用するAPIシークレット。Profileを利用。動きの違いは、今のところログ出力の詳細化だけ。2014-05-08T06:50:33Z)を用いる。各エンドポイントは、特に明示のない限り、下記のようなJSON形式のレスポンスを返す。bodyではないので注意。「jdbc:mysql://DBホスト名:3306/brian」など。↩RDSを作るので少々長め。リモート】クラスメソッドの会社説明会を開催しますクラスメソッドでは、AWS・AI・ビッグデータ・モバイルなどの技術職や営業のメンバーとして一緒にお仕事をする仲間を大募集しています。#cmdevio新型コロナウイルスの感染拡大を受け、本イベントを延期させていただくことになりました(開催時期未定)。お申し込みいただいた皆様には大変申し訳ございませんが、何卒ご理解いただけますようよろしくお願いいたします。AWSについてライトに色んな情報交換をしましょう。カフェ店長のオカノです。今日はオフィスに用があるので、通勤ラッシュを避けて出社しました。この子は新メンバーのさめくんです。在宅勤務が推奨されているのでオフィスが閑散としており、すこしさみしそうです。使いたいときの注意点を書きました。本が出ていたので読んでみたところよかったので紹介させていただきます。