fluentd forwarder を daemon service として登録することで fluentd logging driver 起因の fluentd の負荷を分散させる

Docker の logging driver として fluentd logging driver を使うと、DNS や NLB で複数の fluentd プロセスに負荷を分散させようとしても特定のプロセスに負荷が集中することがあります。それを回避するのに FireLens が使えるという話を次の記事に書きました。

ECS の煩わしいオペレーションをよしなにやってくれるツールを作った

ECS のオペレーションは色々と面倒なものが多いです。例えば、ECS クラスタを EC2 インスタンスで管理している場合、インスタンスの AMI を更新しようと思うと、新しいインスタンスを起動して、古いインスタンスをドレイニングして、古いインスタンスを落とすというオペレーションが発生します。また、ECS サービスの設定のうち、新規作成時にしか設定できない項目を変更しようと思うと、別名のサービスを新しく作成する必要があります。ちょっと設定を変えたいだけなのに名前を変えないといけないのは辛いですよね。

FireLens を使って fluentd logging driver 起因の fluentd の負荷を分散させる

Fluentd aggregator を構成する際に、Route 53 や NLB を使うことで、forwarder では 1 つのエンドポイントを指定しつつ簡単に fluend の台数を増減させることができます。ところが、Docker で fluentd logging driver を使う際にそのエンドポイントを指定すると、一度コネクションが確立されるとずっとそのコネクションが使い回されるため、大量のログを吐くコンテナと接続された fluentd ホストだけが高負荷な状態が続くことになります。
この問題を解消するために FireLens を使ってみたという話です。

ActiveRecord::LockWaitTimeout, ActiveRecord::Deadlocked, ActiveRecord::ConnectionTimeoutError が起きた時に原因調査に役立つ情報を表示する gem を作った

それなりの規模のサービスを運用していると、不可解なエラーに遭遇することはよくあるものです。その中でもデータベース関連のエラーは一見難解な問題に見えるかもしれませんが、原因調査に役立つ情報をさえ出力すればたいていの場合は容易に原因を特定できるものです。というわけで、Rails でよく遭遇するエラーの調査に役立つ情報を出力する gem を作成しました。

Amazon SQS のメッセージを処理するアプリケーションを本番で運用するために考えるべき基本的な 5 つのこと

Amazon SQS は可用性やスケーラビリティの高いメッセジキューサービスであり、AWS の代表的なサービスの 1 つと言えるでしょう。ところが、本番の運用に耐えられるアプリケーションにしようと思うと考えることが意外に多いものです。本エントリーでは簡単なサンプルアプリケーションをベースに、本番で運用するために考慮すべき点について見ていきます。題材として扱うのが SQS なだけで、SQS 以外を使ったアプリケーションにも応用できる内容もあるでしょう。
なお、SQS には Standard queueFIFO queue がありますが、Standard queue を使う前提とします。

Docker のログを columnify で Athena (Presto) に特化した Parquet にする

先日 columnify という、入力データを Parquet フォーマットに変換するツールがリリースされました。
cf. 軽量な Go 製カラムナフォーマット変換ツール columnify を作った話 - Repro Tech Blog

ruby-kafka の consumer group で instance type や availability zone によって特定の partition の lag が大きくなる問題を解消する gem を作った

ruby-kafka を使った consumer のアプリケーションにおいて、次のような前提があるとします。

Amazon SQS の ApproximateAgeOfOldestMessage とは何なのか?

SQS には ApproximateAgeOfOldestMessage という、queue に存在する最も古いメッセージの、queue に入ってからの経過時間に関するメトリクスがあります。例えば queue の処理が遅延していることを検知したい場合、ApproximateNumberOfMessagesVisible よりも良い指標となる場合があります。ただ、このメトリクスの定義の詳細についてはドキュメントに載っておらず、ドキュメントに書かれている内容も正確さを欠くので実験を通して現在の挙動についてまとめてみました。

Aurora MySQL 5.6 と ElastiCache Redis 5.0.6 における並列カウントアップのパフォーマンス比較

MySQL では次のような SQL を書くことで対象レコードの値をインクリメントすることができます。 

Avro でスキーマ管理されたデータを BigQuery で取り込めるデータに変換する

Kafka に入っている Avro フォーマット(スキーマは Schema Registry で管理されている)のデータを BigQuery に取り込みたいとします。その場合、おそらく Google BigQuery Sink Connector を使うのが良いでしょう。
ところが、諸事情により Ruby で Kafka からデータを逐次取得し、BigQuery にデータを取り込みたいとします。その場合、fluentd のある環境であれば、取り出したデータを fluentd に送り、fluent-plugin-bigquery で取り込むのが手軽でしょう。

広告