Sendを書きました。SendGridgithub.comREADMEのUsageを見ればわかるとおり、ほぼAPIに即した薄いクライアントです。現状で公式クライアントは利用しにくいので、自作した感じです。Schemaで行うようにしています。あー、sendメソッドが使いにくかったせいか)method_missingを使ったかなり薄いラッパーでメソッドやパラメータのチェックが弱い。ヘルパークラスも空白などを除去しているだけでチェックの役に立っていない気になる書き方がいくつか(固定文字列のJSONをわざわざパースしてHashにしている・必須引数に空白のデフォルト値を設定している)といった感じで、うーん...とクビをかしげる状態になっています。v1からv2への変更で大幅に修正が入っていて、なぜこのようなわかりにくいインターフェースになったのか、ぜんぜん経緯を理解できていないです。Schemaでパリデーションするようにしています。リクエストパラメーターのバリデーションができれば、インターフェースはシンプルになりそうですが、公式クライアントはなんか頑張っている?せいで煩雑です。API定義はしっかりしているように見えるので、そこからどうとでもクライアントは生成できると思うのですが、なんでこんな状況になっているのかよくわからない...わからない。oas.jsonからクライアントを自動生成できそうだけど。参照すればちょちょいのちょい...と思っていたんですが、oas.jsonのdefinitions、足りなくないですかね。email_objectとか。v0.7.6でignoreという属性をつけられるようにしたridgeporeのv0.7.6でignoreという属性をカラム・インデックス・FKにつけられるようにした。github.comあんまり周知していなかったせいで、全然知られていないが、ridgepoleでもexecuteがつかえる。SQLend冪等性を担保するために少しだけ拡張していて、ブロック内の返り値がtrueの場合のみ、executeを実行するようにしている。ブロックにはコネクションを渡しているので、存在チェックをすることで重複してexecuteが実行されないようにすることができる。...が、たとえばN-gramのフルテキストインデックスのように、Railsが対応していないカラムやインデックスをexecuteで作成しようとするとめんどくさいことになる。}.include?('ft_index')endのような感じでインデックスを貼ろうと思うと、先に「N-gramではないインデックス」が作成されてしまって、「N-gramのインデックス」はexecuteでは作成されなくなる。executeのブロック内のクエリで頑張って「N-gramではない場合は再作成」というようにすれば、「N-gramのインデックス」を貼ることはできるが、流石にめんどくさいので、カラムやインデックスにignoreという属性をもたせることにした。trueがついたカラム・インデックス・FKについては、ridgepoleは無視、全く変更に関与しないようにしている(つもり)。このスキーマ定義はRailsでは対応していない「N-gramのインデックス」を冪等性を保ったまま作成することができる(はず)。テストが通ったらリリースする予定。v0.7.6でignoreという属性をつけられるようにしたTweetもっと読むコメントを書く2018-12-17apexでrubyをデプロイするちょうど4日ほど前に、apexにrubyサポートのPRがマージされていた。github.comなので、すこし試してみた。apexのビルドgoのバージョンは1.11.4。GO111MODULE=onでビルド・インストールできた。1.0.0-rc2lambdaファンクションのデプロイディレクトリ構成はこんな感じ。project.jsonデフォルトのファイル名はlamba.rbでハンドラ名はhandler。my_ruby{"hello":"world"}Gemの同梱bundlerでpathを指定すれば普通にできた。"bundler/setup"とかは不要なよう。Linuxで拡張を作成しないとだめっぽい?ので、こちらを参考にDockerイメージを作成。Linuxが必要というわけじゃなくて、rbenvでインストールしたC拡張にlibruby.so.2.5へのリンクがないせいじゃないだろうか?miscapexのアクティビティをみると、先行き不安な気がする。23:20apexでrubyをデプロイするTweetもっと読むコメントを書く2018-11-19active_record_mysql_xverifyactive_record_mysql_xverifyというgemファイルを書いた。github.comこれは何?RailsでAuroraを使うときに、フェイルオーバー時に旧マスタにつなぎに行く問題をなんとかするやつ。世間様を見渡すに「コネクションプール使うな。接続を切れ」というのが現状の解決策のようだけど、もうちょっとなんとかしたかったので作成。ActiveRecordMysqlXverify::Verifiers::AURORA_MASTERと書いておくと、いい感じにしてくれます。splittingをしして、コネクション毎に有効にするかしないかを分けたい場合はActiveRecordMysqlXverify.handle_ifを使ってください。falseとしてください。実装についてRailsはコネクションプールからのチェックアウト時にverify!を実行して*1、検証に失敗すると再接続する*2ようになっているので、verify!を上書きしてinnodb_read_onlyを見るようにしただけです。variablesを実行するのもアレなので、デフォルトではエラー時のみ。failoverでやっていることはSQLを実行エラーをハンドリング再接続SQLを再実行というのが大きな流れのようだった。エラーハンドリングの判断にエラーの種別を見たり、別スレッドでコネクションの状態をチェックしていたり*3、といろいろやっているけれど、基本的にはactiverecord-mysql-reconnectと変わらないような気がする。トランザクションが切れた状態でのSQLの再実行って、トラブルありそうだけどあんまり問題になってないのかな?ActiveRecord::QueryCacheコネクションプールからのcheckoutとcheckinのタイミングが重要なので、ActiveRecordのコードをちまちま読んでいたんだけれど、Rails5でQueryCacheはRackのミドルウェアじゃなくなってた*4。checkoutは最初にコネクションにアクセスしたタイミングでされるけど*5、checkinはQueryCacheに依存している気がする*6。ミドルウェアじゃなくなったのも、その辺の「コネクションプールの管理に必須だから」みたいな判断もあるのかな?あるいは単にAPIの変更の影響だろうか?QueryCacheのレイヤが完全に削除されるとcheckinが機能しなくなりそうなんだけど、そのへんどうなんだろう?よくわからない。18:47active_record_mysql_xverifyTweetもっと読むコメントを書く2018-11-04audit.logのパーサを書いた先日、Kyoto.rbがあったので、参加してもくもくとLinuxのauidt.logのパーサを書いてきた。/var/log/foo3.log"フォーマットについては、公式のWikiがやや詳しいような気がする。パーサぐらいその辺にありそうだと思って、いろいろ探してみたけれど、結局見つからなかったのでRubyで書いた。パーサを書いたついで...というかこっちが本命だけれど、fluentdのfilterプラグインも書いた。github.comaudit.logはrsyslogに対応しているので、集約のためにfluentdを使う必要はないんだけれど、集約先でいろいろ加工してほかのサービスに送ったりするには、やはりfluentdが便利。(追記)ausearchで絞り込めているのを見ると、内部的に何らかのパース処理をやっていると思うんだけど。ソースコード読まねば。12:19audit.logのパーサを書いたTweetもっと読むコメントを書く2018-08-29Postfixでの流量制限についてそろそろ腐りそうな知見なので、腐りきる前にメモだけ残しておく。基本的にはSendGridなどのクラウドサービスを使った方がいいと思うけど、どこかの誰かの役に立つかもしれないので...Postfixでメール配信の流量制限を行う場合、送る量を制限するか、MTAに入ってくる量を制限するかの2通りの方法があると思う。送る量を制限しようと思うとslow_destination_rate_delay=1sみたいな設定値を追加して、送信毎に遅延をかけるような感じになると思う。knowledge4linux.blogspot.comしかし、この方法だと1s以下に設定することができないので、毎分何万通も送るようなシステムだと極端に配信量が下がってしまう。流量制限を行う場合は単に遅延を設けるだけでなく「毎分xxx通」といった厳密な指定がしたい。そこで、MTAに入ってくる量を制限する。単純にMTAに入ってくる量を制限すると、上限超えたときにクライアントでエラーが出る。以下のようにPostfixを2段構成にする。smtpd_client_message_rate_limit=400クライアントに面したPostfixでは流量制限したい宛先のポートをtransportで変更する。smtp:[outside-load-balancer]:11126また、main.cfで再送間隔を短くしておく。3mこういう構成にしておくと、gmail宛には1000通/分、docomo宛には400通/分、みたいな感じで流量を制限することができる。経験上、3キャリアとGMailについては流量に制限をかけておいた方が無難だと思う...またこの構成でのもう一つのメリットは、流量制限によってメールが溜まるキューがインターネット側のPostfixではなく、クライアント側のPostfixであるという点だ。Postfixのキューにメールが溜まってしまうと、そのIPが大量配信などで受け取り拒否されたときに困ったことになってしまう。クライアント側のキューの方にメールが溜まっている状態なら、流量制限のリミットの引っかかった場合、再送でロードバランサーが別のPostfixに適度に振り分けてくれる。04:24Postfixでの流量制限についてTweetもっと読むコメントを書く2018-08-03DatadogでのECSタスクのCPUの監視についてECSタスクのDockerコンテナのCPU使用率については、監視自体に意味があるのか微妙なところもあるけれど、タスクの制限いっぱいまで常にCPUを使い切っているコンテナは不健康な場合もありそうだということで、Datadogで監視しようとしたことがあった。docker.cpu.usageはホストの1コアに対するCPUの使用率なので、50%となっていても、ECSのタスク定義でCPU=512としていたら、リミットいっぱいいっぱいまで使っていることになるので、タスクやイメージによって閾値を変える必要が出てくる。alertが使えない。docker.cpu.throttledというメトリクスがあってwww.datadoghq.comこれはnr_thresholdの値で、割り当てられたCPU時間の限界に達した数をカウントしてくれるのでこれを見ると良さそうだ...と思ったんだけれど、この値が変動するのは(たしか)--cpusだったか--cpu-quotaだったかのオプションの時で、ECSのタスク定義でつかうcpu=--cpu-sharesの時には変動しない。cpu.sharesの値が取れたので、それで正規化すればいいじゃんということで、パッチを投げた。github.comめでたくマージされ、v6も変更が入って、docker.cpu.sharesというメトリクスが入った。みたいなタスクがあって、値が1000%みたいなことになるということがあって、結果は微妙だった...あんまりこの手の知見が見当たらなかったので、とりあえずメモとして残しておく。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。