「AWSを活用して少人数で複数のサービスを運用するコツ」〜JAWS-UG in Nagoya〜 - よかろうもん！
10月6日に名古屋で開催された第4回JAWS-UGにて、「AWSを活用して少人数で複数のサービスを運用するコツ」というテーマで、SonicGardenの運用に関しての考え方や取り組みについてお話させていただきました。 当日の資料を以下から見えるようにしておきます。 「AWSを活用して少人数で複数のサービスを運用するコツ」〜jawsug in nagoya〜 また、資料のインプットとなっている記事については以下にリンクを用意しておきますので、時間があるときに読んでいただけましたら幸いです。 AWS障害による影響を小さくするための設計(2011/4/21の障害を踏まえて) - よかろうもん！ データやログのバックアップを楽に実現するために活用すべきライブラリ〜Backup〜 - よかろうもん！ 実践で使えるEBSスナップショット取得スクリプト - よかろうもん！ トータルフットボールなチームの
AWS障害による影響を小さくするための設計(2011/4/21の障害を踏まえて) - よかろうもん！
youRoomでの障害対応と、SonicGardenの運用の考え方について、先日id:mat_akiがブログを公開しました。 『youRoomにおいて発生した 2011/4/21 のAWSの障害について技術的な観点から』 今回のブログでは、”今回のAWSの障害を通じて、AWSを今後も活用していくための振り返りを、より技術的な観点からしたいと思います”。 今回は、us-east-1リージョンにおけるEBSのサービス障害が問題となりましたが、この影響を受けて多くのWEBサービスがダウンし、サービス再開までに多くの時間を費やしていました。 なぜEBSのサービス障害で(まだ断定はできませんが...)、これほど広範囲に影響が出たのでしょうか？ Amazon EC2の米国東海岸データセンターで障害、利用サイトに影響 Amazonのクラウドサービスに障害、FoursquareやQuoraなどに影響 アマ
これを知っておかないと、MySQLサーバの再起動でDBデータの不整合が発生するかもしれません！ - よかろうもん！
Railsに限らず、MySQL(Innodb)を利用したサービスを開発/運用しているなら、これから解説する内容を知っておかないと、予期しないデータ不整合を発生させてしまうかもしれません。 データ不整合が発生してしまったら、本来あるべき状態に戻すのはかなり難易度が高いため、開発/運用をしているエンジニアは、データ不整合を起こさないようにすべきです。 では、どのようなことをすると、データ不整合をいとも簡単に発生させることができるかを解説します。 まずは、何が原因でデータ不整合が発生するかの簡単なモデルを紹介します。 以下のようなUserオブジェクトをcreateししたとします。 User.create(:name => "interu, :age => "27") すると、Userテーブルにデータが追加されます。 ■ Userテーブル id name age 1 user_a 30 2 use
データやログのバックアップを楽に実現するために活用すべきライブラリ〜Backup〜 - よかろうもん！
サービスを提供する上で欠かせないのがデータやログ等のバックアップの設定です。 構築/運用するサービスが増えると、その時に必ずバックアップの設定などを行なわなければなりませんね。 ですがこのバックアップを仕込む作業、実に面倒ですよね。 面倒な理由として以下があります。 環境構築の度にアプリケーションの仕組みに合わせたスクリプトを作成しなければならない アプリケーションエンジニアにバックアップ対象を確認しないといけない バックアップしておくデータの世代管理をしないといけない バックアップしたデータからリストアのテストをしないといけない バックアップ失敗時にエラー検出するようにしないといけない バックアップ失敗時にエラー通知のテストをしないといけない ... etc. バックアップの仕組みを整備するのもひと苦労です。 さらに、サービスが増えるごとに上記の作業をくり返しているとホント嫌になりますよ
Facebookから社内ADまで、外部サービスと連携するときに知っておくと役に立つライブラリ - よかろうもん！
外部サービスと連携すると、連携するサービスの状況に依存していろいろなエラーが発生したりします。 例えば外部サービスが高負荷であるために、タイムアウトのエラーが発生したり、強制的にコネクションをリセットされるようなエラーなど様々です。 その状況が発生した際に、利用ユーザにエラー画面を表示したり、再操作を指示するメッセージを表示するのは、ユーザ視点で考えると微妙ですね。 ではどうすればよいでしょうか？ そんなときは、retryableというライブラリ(gem)を利用するとよいです。 このretryableというgemは、名称から推測できるとおり、失敗(エラー)したときにリトライしてれるものです。 例えば、SonicGardenが提供しているサービス『youRoom』では、Facebookアカウントでログインという機能があります。 その認証に稀ではありますが以下のようなエラーが発生することがあり
Passenger + monit でリリース作業をより簡単にする方法 - よかろうもん！
PassengerでRAILSアプリを運用しているなら、アプリのリリース時には、${RAILS_ROOT}/tmp/restart.txt を配置/更新することで、ほぼダウンタイム無し(httpdの再起動なしのため)にリリースしているかと思います。 ただ、アプリケーションのソースコードの影響範囲が、Railsアプリのみだけなら、restart.txtの仕組みだけでよいかもしれません。しかし、パフォーマンスを考慮し非同期処理を行うためにdelayed_jobを利用していたり、メール送信流量を制限するためにar_sendmailなどを利用している場合は、それぞれのデーモンの再起動を行う必要があります。 ＃delayed_jobについては、id:mat_aki(@mat_aki)が紹介している「Railsで非同期処理を行うには"Delayed_job"がおすすめ」がわかりやすいと思います。 その
アプリケーションに依存するバッチを"アプリケーションで自動生成"してcronに登録する方法 - よかろうもん！
バッチ処理で一括処理を行うようなアプリケーションは多いかと思います。 ですがこのバッチ処理の設定をするときに、以下のようなシーンで悩まされることが多々あります。 マニュアル関連の問題として、 マニュアルを読みあさらないとわからない バッチに関する情報が更新されていない 運用に発生しがちなミスとして、 開発者と運用者の間の情報共有でバッチに関する情報が抜け落ちていた などがあります。 これらは、情報の散乱/更新忘れ/伝達ミスなどで発生しますが、もしこれらのバッチ処理に関する情報を"アプリケーションで管理しておき、そのバッチ処理の設定作成までをアプリケーション開発者に任せ、コマンド一発で自動的に設定を生成することができれば"前述したような課題は解決するはずです。 この課題を解決するツールに、"whenever"という gem があります。 ではさっそく、使い方の解説を。 はじめにgemをインス
straceでシステムコールを確認 - よかろうもん！
プロセスにattachしてトレースする時はstraceコマンドを利用する。 利用フォーマットはこんな感じ。 # strace -p [PID] 複数プロセスを同時にattachし、traceする場合は、 # strace -p [PID] -p [PID] f オプションや -F オプションを付けることで、forkおよびvforkした子プロセスもtraceすることが可能になる。 o [出力ファイル名] でtraceログを記録することもできる。 サンプルとして、以下のコマンドを実行して ls コマンドをstraceで追っかけてみる。 # strace -o result.log ls 結果はこんな感じ。 xecve("/bin/ls", ["ls"], [/* 38 vars */]) = 0 brk(0) = 0x805f000 access("/etc/ld.so.nohwcap", F
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
