サイトを運営していると、ときどきメッセージキューで非同期に処理をしたいなという箇所がよくあります。EC2の併用など、異なるクラウド環境を使ったシステムをを扱っており、その連携方法を日々調査しています。使えばよいかと思うのですが、クラウド環境間の連携などを考えると、グローバルに利用できるメッセージ伝達方式の方が望ましいケースもあります。SQSに触手を伸ばし、入門してみました。今日は、その記録を残します。SQSの利用を申し込む」をすればOKです。課金はリクエスト数によるものととデータ転送量によるものの2系統です。SQSリクエストに付き0.01ドル。ほとんどお金かかりません。データ転送量は米国&欧州とアジア(シンガポール)で異なりますが、たとえば、米国&欧州では10TB(テラバイト!!)までのデータ受信で0.15ドル。同一RegionでEC2と送受信するものは課金されません。すごくすごく気軽に使える値段です。機能が少ないともいえますが、シンプルに使えます。だいたいのことはには、以下の4つを使ってできます。メッセージキューからメッセージを削除もちろん、他にもAPIはいろいろありますが、ちょっと試すだけならばこれでOKです。キューを作成したあと、以下の絵のような流れで処理をすることになります。SimpleDBなど外部のデータストアに置いておき、そのポインタをメッセージに入れるのがよいです。【メッセージ保存期間と視認性について】メッセージは4日間、キューに保存されます。同一のメッセージが見えなくなります。見えなくなる時間(視認できなくなる時間)はAPI経由で設定でき、30秒から12時間まで設定できます。Aというクライアントがメッセージαを取得したあと、なにかしらの処理に失敗した場合、メッセージαは、一定期間(30秒~12時間)のあとに、他のクライアントから見えるようになります。そのAというクライアントが処理に成功し、メッセージ削除APIをキューに対して呼び出した場合は、その後、他のクライアントから見えなくなります。~Perlで実際に使ってみる~】PHP編やJava編はいずれ機会があったら書きます。Perlから使ってみます。先ほどの絵でいうところのSendMessageする側(Process1)が「メッセージ送信側」、ReceiveMessageする側が「メッセージ受信側」(Process2)とします。World」とします。World'とメッセージをいれ、メッセージ受信側はそのメッセージをキューから取得、画面に表示してキューからメッセージを削除しています。実運用ではメッセージは処理を依頼する内容やデータのポインタになります。メッセージ受信側では、時間がかかる処理をするなど、なにかしらの処理をします。Perlから使うにはモジュールのインストールが必要です。Amazon::SQS::SimpleというモジュールがCPANにありますので、サンプルプログラムを使うには以下のモジュールをインストールしてから実行する必要があります。Amazon::SQS::Simpleモジュール以下、サンプルプログラムです。SQSオブジェクトを作成します。作成済みの場合に実行してもそのままキューがある状態になります。キューにメッセージを送付します。SQSオブジェクトを作成します。キューオブジェクトを取得します。キューからメッセージを取得します。メッセージの内容を出力してみます。キューからメッセージを削除します。ReceiptHandleというのを使います。SQS並みの信頼性を保とうと思うとけっこう大変です。Q4MのようにMySQLを使うタイプのメッセージキューを自前で構築した場合、1台くらいサーバが落ちてもメッセージをロストすることなく、なおかつ、クライアントからのメッセージ送受信のリクエストをさばきつづける、となると、必要な構築コストはかなり大きいです。複数台のサーバが必要で、MySQLのレプリケーションをしたり、あるいはDRBDで複数台のデータを同期させたり・・・、とかとか。SQSはAmazonが複数のサーバやデータセンターで冗長化していて大量のリクエストが来ても、ちゃんと止まらずにさばいてくれます。いったメッセージキューシステムを自前で作らなくてもすぐに本番システムレベルの信頼性で使える、というのは場合によっては大幅なコスト削減になるんではないかと思います。パフォーマンス面など適合しないケースもあるかと思いますが、クラウドな環境ではひとつの選択肢になるのではないかと考えています。大きいデータの受け渡しが必要なときはS3などにデータをおき、そのポインタ情報(URL)をやりとりするように、ということがあります。同一のメッセージが複数回受信できてしまうことがある。メッセージはキューに入れた順番どおりには受信できない。SQSが複数のサーバや複数のデータセンターを使って運営されているためのようですが、注意が必要です。SimpleDBなど)にどこまでのメッセージ処理ができたか、などの情報を持っておく必要があります。その辺はシステムの要求などによりケースバイケースだと思いますが、注意が必要です。初期調査、入門だけなのに、記事が少しながくなってしまったので、今日はこれくらいにしておきます。SQSの調査の最終ゴールは当社が現在力を入れているSaleforceのシステムと連携させてみることです。連携できたらまた記事にしますので、待っていてください。Servicesに力を入れると同時に、Salesforce事業も展開中です。現在、こういったいろいろなクラウドプラットフォームを使ってお客様によいソリューションを提供したい、というエンジニアの方を大募集中です。興味のある方は以下からご連絡いただけると幸いです。(水)EC2でEBS上のMySQLのデータをバックアップこんにちは。ベターホームレシピ(http://bhmb.jp)では、MySQLを会員やレシピデータ用のインスタンスと、Cicindela用のインスタンスを同一のサーバにそれぞれデータをEBSに置いて運用しています。運用上大事なのはバックアップです。そこで、今日はEBS上のMySQLのデータのスナップショットを整合性を失わずにバックアップする方法についてベターホームレシピでの実運用の事例をもとに紹介します。RDSを使えばよいのではないか、という考えもあります。最近はMulti-AZ機能なども提供され、安心感があります。ベターホームレシピを検討していたときには、RDSは冗長化機能が弱い、バックアップでIOフリーズがあったりする、など現在より課題も多かったのでEC2上で自前運用としました。運用にかけられる予算が少なかったので、EC2とは別に複数のインスタンスでのRDSの費用が発生するのが嫌だったというのもあります。RDSを選ぶかは、みなさまの環境によると思います。EBS上にMySQLデータを置いて動かすでは、EC2上で自前でMySQLを運用する場合について進めます。普通にインストールすると、EC2のローカルストレージにデータを置くことになりますが、EC2のインスタンスが落ちた場合、データ消えてしまうので怖いです。したがって、MySQLのプログラム自体はEC2のローカルストレージでもいいのですが、データディレクトリはEBS上に置くことにします。肝心の方法ですが、以下に書いてある通りですんなりできます。xfsポイントはファイルシステムをxfsで作ることできます。一貫性を持ったファイルシステムのスナップショット取得ができます。今回の用途にはよいです。以下に続く例もxfsにします。手動でフリーズ、スナップショット取得を実行してみる前提としてmysqlのデータファイルは/vol/****/mysql/dataにあるものとします。(****は当社の場合はプロジェクト名です)手順は以下の順番です。MySQLのデータをFLUSHし、READロックをかけます。書き込みできないようにします。これでDBへの書き込みはできなくなります。xfs_freezeコマンドでファイルシステムを凍結。ファイルシステムに書き込みをできなくすると同時に、ファイルシステム上のキャッシュやメタデータなどをディスクに書き込んでしまいます。EBSのスナップショットを取得する。xfsの凍結を解除します。ec2-create-snapshotでできます。MySQLのロックを解除します。DBやファイルシステムの状態が不整合を起こさないようにする工夫は(1)、(2)です。(1)でMySQLのキャッシュのデータをFLUSHし、全部ディスクに退避させ、その上でREADロックです。これでMySQLに追加書き込みはできません。その上で(2)を実施して、ファイルシステムに書き込みできなくします。ディスクに追加書き込みできなくしてからEBSのスナップショット取得、そしてロックを順次解除していきます。具体的には以下のようにmysqlのコンソールに入ってコマンドを実行していくとできます。mysqlのコンソールへ。バックアップのプロセスを自動化する上記のプロセスをスクリプトで自動化しておくと、定期的なスナップショット取得ができて便利です。以下に簡単なPerlでのスクリプト例も書いておきます。xfsを使わない場合も想定して、xfs_freezeの前にsyncを入れていますが、それ以外は上記のプロセスの自動化となっています。注意点、制限事項などベターホームレシピで運用しているときはだいたい1回5秒くらいかかります。EBSスナップショットに時間がかかります。その間、書き込みがブロックされるので注意が必要です。書き込みに待ちが発生してもよい環境(スレーブ環境)などで取得するか、マスタ環境で取得する場合は、書き込みブロックが許容できる環境で実施するのがよいと思います。EBSスナップショットの取得はec2-create-snapshotコマンドではなく、APIを直接たたけばもう少し高速になるはずです。それはまた今度実施してみます。あと今回はxfsにしましたが、ext3,ext4など他のファイルシステムでもxfs_freeze的なことができるのかは、ちょっと調べましたが、見当たりませんでした。他のファイルシステムでもこういったバックアップ運用ができるのか、今後調べてみたいです。今回の記事は以下の記事をもとに作りました。まとめこのような手順を踏めば、定期的に整合性の取れた状態でスナップショットを作っておけて便利です。今度はリストアの方法なども記載したいです。フレクトではEC2を使ったインフラ運用に興味のあるエンジニアを募集しています。興味のある方は以下からご連絡ください。(0)EC2でEBS上のMySQLのデータをバックアップこんにちは。ベターホームレシピ(http://bhmb.jp)では、MySQLを会員やレシピデータ用のインスタンスと、Cicindela用のインスタンスを同一のサーバにそれぞれデータをEBSに置いて運用しています。運用上大事なのはバックアップです。そこで、今日はEBS上のMySQLのデータのスナップショットを整合性を失わずにバックアップする方法についてベターホームレシピでの実運用の事例をもとに紹介します。RDSを使えばよいのではないか、という考えもあります。最近はMulti-AZ機能なども提供され、安心感があります。ベターホームレシピを検討していたときには、RDSは冗長化機能が弱い、バックアップでIOフリーズがあったりする、など現在より課題も多かったのでEC2上で自前運用としました。運用にかけられる予算が少なかったので、EC2とは別に複数のインスタンスでのRDSの費用が発生するのが嫌だったというのもあります。RDSを選ぶかは、みなさまの環境によると思います。EBS上にMySQLデータを置いて動かすでは、EC2上で自前でMySQLを運用する場合について進めます。普通にインストールすると、EC2のローカルストレージにデータを置くことになりますが、EC2のインスタンスが落ちた場合、データ消えてしまうので怖いです。したがって、MySQLのプログラム自体はEC2のローカルストレージでもいいのですが、データディレクトリはEBS上に置くことにします。肝心の方法ですが、以下に書いてある通りですんなりできます。xfsポイントはファイルシステムをxfsで作ることできます。一貫性を持ったファイルシステムのスナップショット取得ができます。今回の用途にはよいです。以下に続く例もxfsにします。手動でフリーズ、スナップショット取得を実行してみる前提としてmysqlのデータファイルは/vol/****/mysql/dataにあるものとします。(****は当社の場合はプロジェクト名です)手順は以下の順番です。MySQLのデータをFLUSHし、READロックをかけます。書き込みできないようにします。これでDBへの書き込みはできなくなります。xfs_freezeコマンドでファイルシステムを凍結。ファイルシステムに書き込みをできなくすると同時に、ファイルシステム上のキャッシュやメタデータなどをディスクに書き込んでしまいます。EBSのスナップショットを取得する。xfsの凍結を解除します。ec2-create-snapshotでできます。MySQLのロックを解除します。DBやファイルシステムの状態が不整合を起こさないようにする工夫は(1)、(2)です。(1)でMySQLのキャッシュのデータをFLUSHし、全部ディスクに退避させ、その上でREADロックです。これでMySQLに追加書き込みはできません。その上で(2)を実施して、ファイルシステムに書き込みできなくします。ディスクに追加書き込みできなくしてからEBSのスナップショット取得、そしてロックを順次解除していきます。具体的には以下のようにmysqlのコンソールに入ってコマンドを実行していくとできます。mysqlのコンソールへ。バックアップのプロセスを自動化する上記のプロセスをスクリプトで自動化しておくと、定期的なスナップショット取得ができて便利です。以下に簡単なPerlでのスクリプト例も書いておきます。xfsを使わない場合も想定して、xfs_freezeの前にsyncを入れていますが、それ以外は上記のプロセスの自動化となっています。注意点、制限事項などベターホームレシピで運用しているときはだいたい1回5秒くらいかかります。EBSスナップショットに時間がかかります。その間、書き込みがブロックされるので注意が必要です。書き込みに待ちが発生してもよい環境(スレーブ環境)などで取得するか、マスタ環境で取得する場合は、書き込みブロックが許容できる環境で実施するのがよいと思います。EBSスナップショットの取得はec2-create-snapshotコマンドではなく、APIを直接たたけばもう少し高速になるはずです。それはまた今度実施してみます。あと今回はxfsにしましたが、ext3,ext4など他のファイルシステムでもxfs_freeze的なことができるのかは、ちょっと調べましたが、見当たりませんでした。他のファイルシステムでもこういったバックアップ運用ができるのか、今後調べてみたいです。今回の記事は以下の記事をもとに作りました。まとめこのような手順を踏めば、定期的に整合性の取れた状態でスナップショットを作っておけて便利です。今度はリストアの方法なども記載したいです。フレクトではEC2を使ったインフラ運用に興味のあるエンジニアを募集しています。興味のある方は以下からご連絡ください。(土)CloudFrontのエッジサーバ上にキャッシュされているオブジェクトを更新するこんにちは。私たちが運営しているベターホームレシピ(http://bhmb.jp)では、画像などの静的コンテンツの配信にCloudFrontを使っています。CloudFrontはAmazonが用意しているS3上のオブジェクトを高速に配信する仕組みです。CloudFrontを使うと、S3のオブジェクトがエンドユーザに対して近くに配置されているサーバ(エッジサーバ)から配信されるようになり、高速のコンテンツの配信ができます。アメリカ西海岸にあるS3の画像が日本国内のエッジサーバにキャッシュされて、高速に配信できたりします。Network)の一種です。S3から取得したオブジェクトはエッジサーバ上にキャッシュされます。キャッシュされる時間はS3のメタデータ(HTTPヘッダなど)にTTLを設定すれば制御できます。以前は24時間が最短でしたが、現在は1時間を最短にできます。Expireヘッダに1時間後の時間を設定するなどすれば、1時間ごとにエッジサーバのオブジェクトは更新されるようになるはずです。詳しくは以下を参考にしてください。キャッシュが1時間単位だとけっこう面倒さて、前置きが長くなりましたが、ベターホームレシピではデザイナが直接S3にアップして静的コンテンツを確認したりします。(もちろん、開発用環境からやりますが)しかし、以下のような問題によくぶつかっていました。・静的コンテンツ(画像、CSS)などを更新しても、HTML内はCloudFrontのURLを指しているので、1時間以上待たないと更新が確認できない。何かとこのキャッシュのタイミングは面倒な作業が発生していました。「CloudFront上のコンテンツをゴリゴリ編集できるようにしたい、もうキャッシュ切れを待つのは面倒」という不満がチーム内(デザイナだけですが)にただよっていました。CloudFrontのInvalidation機能そうしたら、最近以下のような記事を見つけました。API上に実装されたようです。1時間とか1日待つのは面倒ですよね・間違ってエンコードしたビデオファイルをキャッシュから削除などなどがあがっています。PersonalでInvalidation機能の使う「APIが用意されているので、そちらでどうぞ。」http://developer.amazonwebservices.com/connect/kbcategory.jspa?categoryID=213と言いたいところですが、現実的にはうちのデザイナはそこまではやってくれませんし、そんなことを要求したら喧嘩になりそうなのでやめておきます。以下の2つのツールが現状は対応しているようです。Explorer前者で実施してみました。Personalをインストールします。http://m1.mycloudbuddy.com/downloads.htmlメールアドレスなど入力が必要ですが、画面に出てくる指示のままに進めます。Personalのエクスプローラ画面を開いてください。Invalidate」を押してください。Invalidation」を押します。すると、たぶん、5分から10分くらいでキャッシュが無効になっているはずです。リアルタイムじゃないのでご注意ください。Invalidationする前に、該当のオブジェクトを更新するなりしておくとちゃんと確認できます。Listで無効にしたキャッシュオブジェクトのリストが以下のように確認できます。はい、このエントリは若干長いですが、CloudFront上のキャッシュオブジェクトの更新はけっこう簡単です。実際に使うときも技術的なことはほとんど考えなくてよいです。開発者の私しか試していないので、来週、うちのデザイナに試してもらおうと思います。これまでの不満を解消できることでしょう。フレクトではCloudFrontやS3を使ってデザイナと一緒にコンテンツ運用の「よりよい仕組み」を作っていけるエンジニアを募集しています。興味のある方は以下からどうぞ。(0)CloudFrontのエッジサーバ上にキャッシュされているオブジェクトを更新するこんにちは。私たちが運営しているベターホームレシピ(http://bhmb.jp)では、画像などの静的コンテンツの配信にCloudFrontを使っています。CloudFrontはAmazonが用意しているS3上のオブジェクトを高速に配信する仕組みです。CloudFrontを使うと、S3のオブジェクトがエンドユーザに対して近くに配置されているサーバ(エッジサーバ)から配信されるようになり、高速のコンテンツの配信ができます。アメリカ西海岸にあるS3の画像が日本国内のエッジサーバにキャッシュされて、高速に配信できたりします。Network)の一種です。S3から取得したオブジェクトはエッジサーバ上にキャッシュされます。キャッシュされる時間はS3のメタデータ(HTTPヘッダなど)にTTLを設定すれば制御できます。以前は24時間が最短でしたが、現在は1時間を最短にできます。Expireヘッダに1時間後の時間を設定するなどすれば、1時間ごとにエッジサーバのオブジェクトは更新されるようになるはずです。詳しくは以下を参考にしてください。キャッシュが1時間単位だとけっこう面倒さて、前置きが長くなりましたが、ベターホームレシピではデザイナが直接S3にアップして静的コンテンツを確認したりします。(もちろん、開発用環境からやりますが)しかし、以下のような問題によくぶつかっていました。・静的コンテンツ(画像、CSS)などを更新しても、HTML内はCloudFrontのURLを指しているので、1時間以上待たないと更新が確認できない。何かとこのキャッシュのタイミングは面倒な作業が発生していました。「CloudFront上のコンテンツをゴリゴリ編集できるようにしたい、もうキャッシュ切れを待つのは面倒」という不満がチーム内(デザイナだけですが)にただよっていました。CloudFrontのInvalidation機能そうしたら、最近以下のような記事を見つけました。API上に実装されたようです。1時間とか1日待つのは面倒ですよね・間違ってエンコードしたビデオファイルをキャッシュから削除などなどがあがっています。PersonalでInvalidation機能の使う「APIが用意されているので、そちらでどうぞ。」http://developer.amazonwebservices.com/connect/kbcategory.jspa?categoryID=213と言いたいところですが、現実的にはうちのデザイナはそこまではやってくれませんし、そんなことを要求したら喧嘩になりそうなのでやめておきます。以下の2つのツールが現状は対応しているようです。Explorer前者で実施してみました。Personalをインストールします。http://m1.mycloudbuddy.com/downloads.htmlメールアドレスなど入力が必要ですが、画面に出てくる指示のままに進めます。Personalのエクスプローラ画面を開いてください。Invalidate」を押してください。Invalidation」を押します。すると、たぶん、5分から10分くらいでキャッシュが無効になっているはずです。リアルタイムじゃないのでご注意ください。Invalidationする前に、該当のオブジェクトを更新するなりしておくとちゃんと確認できます。Listで無効にしたキャッシュオブジェクトのリストが以下のように確認できます。はい、このエントリは若干長いですが、CloudFront上のキャッシュオブジェクトの更新はけっこう簡単です。実際に使うときも技術的なことはほとんど考えなくてよいです。開発者の私しか試していないので、来週、うちのデザイナに試してもらおうと思います。これまでの不満を解消できることでしょう。フレクトではCloudFrontやS3を使ってデザイナと一緒にコンテンツ運用の「よりよい仕組み」を作っていけるエンジニアを募集しています。興味のある方は以下からどうぞ。・HerokuやAWSなどのクラウドプラットフォーム上でのWebアプリケーション開発をする、エンジニアを募集中です。【得意分野/業務分野】B2Cのサイト開発を主な業務領域とするシステムエンジニアです。あと、Salesforce.com認定デベロッパーです。AW、Salesforce、システム基盤構築・運用、サーバ/インフラ構築・運用が今の注力分野です。