ActiveRecord::LockWaitTimeout, ActiveRecord::Deadlocked, ActiveRecord::ConnectionTimeoutError が起きた時に原因調査に役立つ情報を表示する gem を作った
それなりの規模のサービスを運用していると、不可解なエラーに遭遇することはよくあるものです。その中でもデータベース関連のエラーは一見難解な問題に見えるかもしれませんが、原因調査に役立つ情報をさえ出力すればたいていの場合は容易に原因を特定できるものです。というわけで、Rails でよく遭遇するエラーの調査に役立つ情報を出力する gem を作成しました。 activerecord-debug_errors 現在次のエラーをサポートしています。 ActiveRecord::LockWaitTimeout (MySQL のみ) ActiveRecord::Deadlocked (MySQL のみ) ActiveRecord::ConnectionTimeoutError 以下、具体的な例を用いてどのような情報が表示されるか説明します。 ActiveRecord::LockWaitTimeout Ac
Amazon SQS を使ったアプリケーションを本番で運用する際に考慮すべき基本的な 5 つのこと
Amazon SQS は可用性やスケーラビリティの高いメッセジキューサービスであり、AWS の代表的なサービスの 1 つと言えるでしょう。ところが、本番の運用に耐えられるアプリケーションにしようと思うと考えることが意外に多いものです。本エントリーでは簡単なサンプルアプリケーションをベースに、本番で運用するために考慮すべき点・注意点について見ていきます。題材として扱うのが SQS なだけで、SQS 以外を使ったアプリケーションにも応用できる内容もあるでしょう。 なお、SQS には Standard queue と FIFO queue がありますが、Standard queue を使う前提とします。 アジェンダは次のとおりです。 サンプルアプリケーション 1. ログ 2. At-least-once delivery と visibility timeout 3. デプロイ 4. 異常系 5
Presto における Service Discovery の動作原理
Presto を運用していると “No worker nodes available” というエラーに遭遇することがあります。これは coordinator が planning をする際に active な worker nodes が存在しないと起きるエラーなんですが、worker nodes に問題ではなく service discovery が上手く機能していなくて起きることがあります。 worker nodes が異常なのか service discovery が上手く機能していないのかを切り分けるには、Presto がどのように service discovery を実現しているかを理解している必要がありますが、よくわかってなかったので調べてみました。 環境は Amazon Elastic MapReduce (EMR) ではじめる Presto 入門と同じく、Presto 0
ECS タスクの終了時にコンテナの依存関係が考慮されない問題を解決するコマンドを作った
ECS タスクは、起動時にはコンテナの依存関係を考慮するのに終了時は全く考慮しません。次のコメントからもよくわかります。 A container can always stop, die, or reach whatever other state it wants regardless of what dependencies it has cf. agent/engine/dependencygraph/graph.go#L179-L180 これの何が問題かというと、fluentd のようなデータ収集用のサイドカーコンテナが動いている場合に、メインのコンテナよりも先にサイドカーコンテナが停止してデータが消失するということが起きてしまいます。 このことは 2 年半前から issue に上がっているんですが、未だに解決されていません。 cf. Termination order of li
Repro 株式会社に入社しました
社内インタビュー記事でご存知の方もいるかもしれませんが、今年の 8/1 に Repro 株式会社 に入社しました。 Repro を運営している会社です。Repro はグロースハックツールと紹介されることが多いですが、アプリに SDK を組み込むことでコホート分析、ファネル分析等のアナリティクス機能や特定の条件を満たすユーザにプッシュ通知を送ったり、アプリ上でメッセージを表示したりする機能などを提供しているサービスです。 入社して最初のタスクの予定だった Rails 5.1 へのアップグレードがようやく一段落したので近況報告です。 前職では何をやっていたか？ 主に Rails を使ったサービス開発をしていました。あとは検索っぽいことをやったり、検索用のインデックスを作ったりするのに自然言語処理っぽいこともやったりしました。 個人ブログに書けるような内容しか書いてないですが、開発者ブログも参考
論理型の設定値を RDB に保存する場合の選択肢と各々のメリット・デメリット
ユーザごとに特定の機能に対して ON/OFF の設定値を持たせることはよくあると思います。 RDB にそのような設定情報を持たせる場合の選択肢として大きく次の 5 つが考えるんじゃないかと思います。 設定項目ごとにカラムを割り当てる 設定項目ごとにレコードを割り当てる（追記：アンチパターンという意見があるので最後に補足を書きました） 設定項目ごとにテーブルを割り当てる（自分は思い付かなかった） 設定項目ごとに 1 つの整数型カラムの 1 bit を割り当てる 1 つのカラムに JSON 等で全ての設定情報を持たせる データベース理論的には 1, 2, 3 以外の選択肢はない気がしますが、実用上は 4, 5 も良い選択となることがあるので、メリット・デメリットを考えて選択する必要があると思います。 そんなわけで、それぞれの選択肢に関してメリット・デメリットを自分なりに考えてみました。 考慮す
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
