Aurora ServerlessとECS Fargateで動くRailsアプリのクエリチューニングをした

tl; dr

  • Aurora Serverlessの場合はスロークエリログ有効化設定がAWS上にある
  • DataAPIを有効化すればクエリ叩き放題で最高
  • チューニングのためのはじめの一歩として、パフォーマンス計測のための環境整備をインフラやアプリに合わせて適宜構築するのが大事

結果としてやったことはただ単純にslow query logを有効化して該当のクエリをexplainして直しただけ

前提

アプリケーションサーバ

DB

  • Aurora Serverless
  • MySQL 5.6

インフラの構成管理にはAWS CDK経由でCloudFormationを利用

準備

まずスロークエリログを見たい or APMでアプリのボトルネックを見たい、というところからスタート
スロークエリログ有効化の方が手っ取り早いし多分クエリが遅いはずだと思ってたのでひとまずスロークエリログから着手した

スロークエリログ有効化

Aurora Serverlessを利用している関係で直接MySQLのログを見ることは出来ない
CloudWatchLogsに吐かせる設定がコンソールやCFnなどから出来るのでその設定をした

参考:

Aurora ServerlessでログをCloudWatch Logsへ出力可能になりました | DevelopersIO

*aws-cdk@0.20.0 を利用(古いのはご愛嬌)

const dbParameterGroup = new rds.ClusterParameterGroup(this, 'DBParameterGroup', {
      family: 'aurora5.6',
      description: `Parameter Groups`,
      parameters: {
        slow_query_log: 1,
      },
    });
    const cluster = new rds.cloudformation.DBClusterResource(this, 'Database', {
      dbClusterParameterGroupName: dbParameterGroup.parameterGroupName,
      // 中略
    });

スロークエリログで何度も叩かれてそうな上に遅いクエリを見つけたのでとりあえずそいつをexplainしたいということになったので今度はその準備をすることに。

DBインスタンスにクエリを実行する

結論としては、Aurora ServerlessのDataAPIを有効化してAWSコンソールから直接クエリできるQueryEditorを利用した
参考: Amazon Aurora ServerlessでManagement Consoleからクエリが実行可能になりました | DevelopersIO

他の選択肢はこんな感じだった

  • ecs-cliのrunコマンド経由でrails runnerを利用してモデルのクエリをexplainする
    • ECSタスクを毎回立ち上げてクエリしてその結果をCloudWatchLogsで確認、という流れなので死ぬほど面倒
  • gatewayサーバー立ててssh
    • EC2立てるだけっちゃだけだけど、その辺手慣れてるメンバーがチームにいないので微妙に腰が重かったしお金もかかる
  • ALBで一時的にVPCトンネルをつくる・・・?
    • 風のうわさでそういうことが出来ると聞いたけどよくわからなかった

結果

ここまででスロークエリを探してexplain出来るようになったので、該当のクエリを見てみたらwhereされてないサブクエリの結果セットが80万行とかになっていたのが原因ということが判明
適当にモデルのクエリを調整していい感じに速くなった。めでたしめでたし。

APMについて

チューニングしたときには活用しなかったけどちょろっと調べたり動かしたりしたので一応メモ

あがった選択肢

  • NewRelic
    • gem入れるだけで動かせてお手軽
    • ECSの料金体系についてドキュメントがなく、問い合わせて見積もりもらわないとわからないので会社員的に地味に辛め
      • *そのぐらいポンッと使わせてくれない会社が悪いという説もある
  • AWS X-Ray
    • ECSの場合エージェント用のタスクを立ち上げる必要があるのでNewRelicに比べると導入めんどい
    • ドキュメントにもRailsのサンプルがなく、多少試行錯誤しそうだったので動かして見るところまではまだやってない
  • DataDog APM
    • NewRelicよりは安そうだった
    • あまりちゃんと調べてない

感想

Aurora Serverlessが便利だった(こなみかん)


実はこのクエリチューニングはチームで1日時間をとってISUCON大会と称して合宿したときの成果で、それはそれで良かったという話もあったり。
スロークエリを探しつつAPMをアプリ得意な人が準備したり、explainするときに何見ればいいのかとか横からアドバイスもらったりしながらワイワイやれて楽しかった。

うちのチームは様々な事情でバックエンドエンジニア不足のためにこの手のタスクの進みが悪いので、こうやってISUCON大会してガッと進められたのはめっちゃよかった

6月の新刊が多すぎるのでメモる

amzn.to amzn.to amzn.to amzn.to amzn.to うちの娘の為ならば、俺はもしかしたら魔王も倒せるかもしれない。 5
トニカクカワイイ(6)
私に天使が舞い降りた!6
君に愛されて痛かった(3)
ブルーピリオド(5)
舞妓さんちのまかないさん (10)
ダーウィンズゲーム(18)
初恋ゾンビ (17)

scansnapでスキャンした画像を自前で用意したプログラムで処理する

tl;dr

  • 連携するアプリケーションという設定 で、1回の取り込みが終わったタイミングで呼び出すexeファイルを指定できる
  • exeファイルは読み込んだファイルのファイルパスをコマンドライン引数で一括で渡してくれる
  • なので、コマンドライン引数を処理するプログラムをexeファイルとして固めることができれば自前のプログラムで自由に触ることができる

ということをやるプログラムを書いた

github.com

やったこと

  • nodeのプログラムをexeに固めるビルド環境の整備
  • Macでの開発環境作った
  • Windows環境のexeファイル呼び出しあれこれを調整

nodeのプログラムをexeに固めるビルド環境の整備

  • nexe をつかうだけ
  • Windows環境下で使う場合、Windowsでnexeを実行すれば何も考えずにexeファイルが作れる

Macでの開発環境作った

Windows環境でnode書くのいろいろしんどい(Macキーバインド違う、win周り疎いのでターミナル環境でハマる(素でnpx使えないのビビった))ので、Macで開発できるようにした

  • nexeの引数でwindows向けビルドを出来るように
    • -t win32-x86-10.13.0 で動いた
    • が、 win32-x86-10.13.0が何を指すのか全くわかってなくて辛い
  • バイナリをDropboxに吐き出すように調整
  • 基本的な動作確認はエントリポイントのファイルを nodeで叩けば良いので特に考える必要がない

Windows環境のexeファイル呼び出しあれこれを調整

  • PATH設定して再起動
  • exeファイル呼び出しで何もしないと実行が終わり次第ターミナルが落ちるので、readline.createInterfaceで待ち受けるようにしたり、ログをファイルに落とせるようにしたり

Macの環境作るのに一番ハマったので、我慢してwin環境で書けばよかったかも。。
やること自体はただのファイルコピーみたいなもんだし

やろうと思ってやらなかったこと

  • バイナリ公開
    • 誰得感あったのでやめた
    • cloneしてビルドコマンド叩いてもらえれば使えるしまあええやろみたいな気分
  • 対話インターフェース作って保存先調整したりしよう
    • 取り込み作業がめんどくなるのでやらんでいいかなと言う気持ちに
  • テスト・CI
    • travisがwin環境提供し始めたらしいし、exeビルドしてe2eテストとか書くと安心感あるかなと思ったけどめんどくさくて未着手
    • readline で待ち受けるところとかがね・・・
    • 気が向いたらやるかも?

SlackをTwitterのタイムラインライクに閲覧できるクライアントを作った

予定だったけどちゃんと作れた。やったぜ。
感想っぽい内容なのでQiitaではなくブログにしといた
というわけで簡単に振り返り

続きを読む

Reactで管理画面を作る際のComopnentライブラリ選定メモ

考えをまとめるためにメモ。

目指すところ

  • 手早く・楽して作る

アプローチ

  • 全部自分で作る
  • CSSフレームワークを自前でラップし、その他は単目的ライブラリを探して使う
  • Bootstrap/Material Designなどを実装したライブラリをベースにしてその他を自分で作ったり単目的ライブラリを探して使う
  • 全部入り(管理画面用コンポーネントライブラリ)を使う

全部自分で作る

文字通り、デザインもCSS書くのも動きをつけるJSを実装するのも全て自前でやる

メリット

  • 全て自分で制御できるので、ライブラリ使っててよくある「これが出来ないの困るんだけど」みたいなことにならない
  • ライブラリ探しとか考えなくていい

デメリット

  • UIデザインが出来ないと話にならない
  • とにかく実装に時間がかかる
  • クオリティ担保が大変

CSSフレームワークを自前でラップし、その他は単目的ライブラリを探して使う

BootstrapなどのライブラリのCSSを自前で作ったComponentに記述して使う

メリット

  • JSの世界については全て自分で制御できるので、ベースになるCSSフレームワークの制御をかなり自由に実装できる
  • CSSフレームワークの恩恵(Gridレイアウトを簡単に使える、ちょっと洒落たデザインをすぐ実装できる)を得られる
  • マイナーなCSSフレームワークで、React実装がないものでも自分で実装するので関係なく活用できるので選択肢の幅が広い

デメリット

  • 全て自前実装に比べてマシだけどやっぱり実装が大変
  • 大抵の場合jQueryとの共存を考える必要がある
  • ライブラリくささが出る(Bootstrap感を隠せない感じ)

Bootstrap/Material Designなどを実装したライブラリをベースにしてその他を自分で作ったり単目的ライブラリを探して使う

reactstrapなどを使う

メリット

  • Gridなどを簡単に実装できる
  • 最低限作るのに道具が揃ってるのである程度手早く実装できる

デメリット

  • ライブラリくささが出る
  • bs,mdのComponentライブラリの細かいデザイン調整は案外手間がかかるっぽい(あんまり詳しくないけど)

全部入り(管理画面用コンポーネントライブラリ)を使う

CoreUIなどを使う

メリット

  • 提供されているものの範疇で実装するなら一番手軽
  • 定番のUIライブラリとちょっと違ったデザインを利用できるのでただBootstrapを使ったものと差別化できる

デメリット

  • 有償のものが多い
    • =利用者が多くないので、利用方法の模索が大変そう・バグを踏んだときが不安
  • React Componentが提供されている物が少ない

上から順に自由度が下がっていく感じ。

今までは手なりで「Bootstrap/Material Designなどを実装したライブラリをベースにして〜」でやってきたけど今回はどうしようかなあ

最近覚えたりやったりしたことを列挙

こんなことやったなぁを書いておこうと思った。

Scala

型クラス

ぶっちゃけプロダクトでどう使えばいいのか全然ピンとこなかったのでもう忘れた...
型クラスがあることによってどんなことを型で表現するからメリットになるのか?の例が知りたい

scalikejdbcとscalikejdbc-bigquery触った

この辺

github.com

ついでにtypesafe-configとかも。
当初の目的としてはscalikejdbc-bigqueryをゴニョるために触った感じ。
普段のプロジェクトではいろいろなライブラリを使ってる関係で生scalikejdbcを触る機会が全然ないので適当に触って、クエリを発行できるようになるまでどんな手順でやればいいのかとかを適当に触った

=:=

型の同一性チェックができる(雑)

mockitoのeqをscalaで使う

Scalaには eq が存在してるのでインポート時に別名でインポートしないと使えない(ハマった

ScalaからCLIツール(具体的には gsutil コマンド)を叩く実装を書いた

要件として、

  • コマンドはなるべく複数並列で叩きたいし、並列数も制御したい
  • コマンドが応答しなくなったら並列で実行中のプロセスをkillしてからScalaのプロセスもちゃんと落としたい

というのがあって、Futureで並列度を制御しつつ、プロセスをkill出来るような実装を頭悩ませて実装したりした
jsでもCLIのラッパー書いたことあるけどキツかったので、CLIのラッパーはどの言語でやってもきついのかもしれない・・・

infra系

Ansible少々触った

  • task,role,inventoryあたりの概念多少知った
  • ユーザー定義の関数を作れるらしいと知った(作ったことはない)
  • スクランナー化したAnsibleは地獄だと知った(弊プロダクトのインフラはそうなってしまっている)
  • 変数の出処を探すのが大変なのでシンプルに保とうという気分になった
  • あと宣言的になるように、とかね。。。

CloudFormation少々触った

  • スタック・変更セット・アウトプット・userdataあたりの概念を知った
  • 順当に運用するのが普通に難しいということがわかった
  • Ansibleに比べて変更の頻度が少ないし、作り直しみたいなことも普通はしないので、「冪等性を保つ」のが意識されにくい
    • 最新のテンプレートだけを反映すればOKという状態になっていない不具合が起きてしまっていた
    • 作って壊してを頻繁に実施するような運用にしたほうがいいのかもしれない
    • インフラ系は触り始めて日が浅いので、ベストプラクティス・・・というかうちの事情を踏まえた上でどうすれば改善できるのか?というのがあまりわからない
  • GCPのDeploymentManagerも多分似た話があるんだけど、こっちは今いるプロダクトだとCFnよりさらにめったに触らないので逆に問題が起きにくい感じがある

Storage Transfer Serviceを毎時集計に使うようにした

EMRでサマった結果をBQでロードするためにS3→GCSへ移動するのに利用。
どうやらこのTransfer ServiceはGCP上の共通のリソースを使っているらしくて、他のProjectがTransferのリソースを使いまくってるときにこちらもアオリを食らうということがあったりしてひどい目にあった
アレ本番運用で定常的に使ってる人がいたらどうしてるのか聞きたい・・・

なおうちはgsutil rsyncコマンドで対処できるように、という対応をしました

CircleCI

この辺↓のことをやった

qiita.com

qiita.com

社内ISUCONが楽しかった話

8/17に社内の催し物としてISUCONをやりました。
楽しかったのでやったことを書き起こしてみます。

なお、問題は以下のY!SUCONから出題でした。 github.com

自分のスキルセット

  • フロントエンドエンジニア
  • ここ1年半ぐらいスクラムマスターやってた
  • 最近はScalaで集計周りのコードを書いたりインフラ周り(主にAnsibleやCFnなど)をほんのちょびっと

ISUCONで動けるタイプの人間じゃない・・・

事前準備

チームのメンバーが、主にアプリケーションエンジニアだけど上から下まで一通り触る競プロマンと機械学習系が強いマン。
相談した結果、競プロマン氏がインフラやらミドルウェア周りを中心、自分と機械学習マンでひとまずアプリ周りという方向になりました。

アプリはいったん自分が得意としてるJavaScript実装でスタートすることに。

リポジトリの用意・最低限の環境構築・ブラウザで業務用に開いてるタブを閉じるあたり。

本番

競技時間はおおよそ10:00開始で17:00にベンチ用のインスタンスのシャットダウン
開始時間がおおよそなのは朝は集まりが悪いので時間が確定しにくい問題があったりなかったり

10:00 ~ 10:30

  • とりあえず落ち着いて開発できる席を探して着席したら.ssh/config作ってインスタンスへログインできるように確認
  • ひとまずベンチ回す
  • アプリコードをリポジトリにいれてpushしたりデプロイスクリプトの作成に入ったり
  • アプリコード読んだり

こんな感じでエンドポイント列挙したりした f:id:sisisin444:20180817235351j:plain

10:30 ~ 12:00ぐらい

(若干時系列バラバラ

  • alpやらnginxのアクセスログやらを見れる環境を用意
  • アプリをローカルで動かすのがんばったり
  • アプリ側のパラメータ弄るだけで良さそうなところをひとまずなおした(mysqlのconnection limit1 -> 10)
  • 計測してなかったんで重いエンドポイントわからんかったけど /searchが怪しそうとアタリを付ける
  • マイクロサービスになってたアプリの統合をした方が良さそうだったので、ひとまずDBが分かれてたのを統合した

    • アプリ側はまだ普通にマイクロサービスへリクエスト投げまくってる
  • 11:30ぐらいに計測結果が出て、 //searchがクソ重いことがわかる

    • ここで / を何とかしようという方向に

11:30 ~ 13:30ぐらい

  • 競プロマンがとりあえずとってきたtweetsテーブルの結果だけuserテーブルをクエリしていたのでJOIN
    • ここでベンチが全然数字変わらずハマる。
    • デプロイスクリプトがバグっていたのが原因っぽい
    • ・・・と思いきやちゃんとデプロイしても数字伸びない
  • その間自分はマイクロサービスをモノリシックにする修正を入れたり
    • 何故かBadGatewayが出てハマる
    • ローカルでは動くし原因がわからない・・・
    • 1時間ほど慌てた結果、全部モノリシックにするのは諦めて、GET /:meだけを統合(POST,DELETEで使ってるエンドポイントの follow, unfollowはそんなに重くなかったので)したら通った
  • モノリシック化をいれてベンチするけどあんまり変わらず(たしか1000ぐらい)。もっと重い部分が別にあったのでこれは予想通り
  • friendsテーブルの正規化をやるかどうかを悩んででかい実装になるので今からこれやりきる自信がないと判断してやめ。

(ここまでスコアは全く伸びてないので地味に焦り始めてました

13:30 ~ 14:30ぐらい

  • 他の人は重いクエリを調べたり考えたりしていたっぽい(自分はあんまり把握してない)
  • 自分はJOINで絶対数字上がるはずだと思って、競プロマンの書いたJOINをさらに修正
    • WHEREにnameの検索を追加
    • LIMITを追加

ここでベンチして7000点を記録する。
他のチームが2000~3000ぐらいをうろついてたので頭一つ飛び出たのでヨッシャになった。
が、エラーが出ていたので全員で何とかしようという話に(今回のレギュレーションではエラーが出てると0点扱い)

14:30 ~ 15:00ぐらい

  • どこがエラーなのかさっぱりわからん状況が続く
  • 競プロマンがnginxのログを見て500返したり返してなかったりを発見
    • nginxのconfをここで初めてまともに見る
  • worker_processesが1になってていかにも怪しいのでとりあえずautoにした
    • ベンチが9000点になってエラーなしを記録してガッツポーズ
  • ↑の修正は / に閉じていたので、 /searchにも適用した
    • 検索条件はいったんLIKEで
    • 15000点ぐらいになった
    • が、またエラーが出る

15:00 ~ 16:45ぐらい

この時間はずっとエラーが出ていた奴と戦っていた。

またアプリじゃなくてミドルウェアが怪しいだろうという事でミドルウェア周りを手分けしてチューニングする方向で調査

innodb_buffer_pool_size = 1G
innodb_flush_log_at_trx_commit = 0
innodb_flush_method=O_DIRECT
  • 静的ファイルをnginxで返すようにしたり
  • 本当にアプリのエラーじゃないことを確かめるためにアプリにloggerを仕込んだり(ここを自前で実装せざるを得なかったのが自分のサーバサイドnode経験のなさの表れだったなあという気持ち)

他チームの追い上げもあったのでなんとしても通したいという気持ちだった中、とあるチームが突然45000点を出してきて無事死亡の気持ちを得る。

16:45 ~ 17:00

  • ミドルウェア周りのエラーだろうと思ってアプリのパフォーマンスをわざと落とす実装を入れてベンチ回したりする悪あがきしてた
    • 結局何度か回してエラー出たのでやめた
  • nginxで弄れるところないかを一生探し続けていたけどだめだった
  • 45000点のチームが何度かベンチして点数をどんどん下げてきていたので何らかの事情でrevertしてるんだろうという感じで、ワンチャンまだある!!!って感じだった

が、結局15000点のベンチを通せずじまい。
最終的に、15:00頃に通った9000点前後のスコアとなった。

結果発表

16:30頃に45000点ぐらいを出したチームが17000点程度まで落としたものの、優勝となった。
うちは9000ぐらい。

お気持ち↓

お開きになった後に反省会で話したこと

  • nginxのアクセスログじゃなくてエラーログ見たら?と指摘されて、見てみたら「Too many open files」が出ていたのを発見 以下の記事を参考に worker_rlimit_nofile をいじったら22000点でた

nginx で Too many open files エラーに対処する - Shin x blog

ぐぬぬぬぬぬぬぬぬ・・・・

  • アプリのloggerは真っ先に入れとくべきだった
  • 完全モノリシック化を諦めたのはナイス判断だった
  • ミドルウェア周りの知見なさすぎて辛かった
  • 想定回答とか見ても全然ベンチの伸び方がかみ合わないんだけど~ってなってた
    • 他のチームもJOINしたりインデックス張ったりしてもベンチ伸びないって言ってた
    • 結局どこがボトルネックなのかよーわからんかった。
  • 足回り整理マンほんと助かる・・・
  • 自分が割と取りこぼしありつつもゴリっとやるタイプで、チームメイトが問題発見とかが得意なタイプだったので自分の弱点を補ってもらえたなぁという気持ちがあった
  • めっちゃたのしかった!

感想

フロントマンが活躍するシーンあるんかいなって感じだったけど、アプリの改善ポイント多めに用意されてた感じがしたので、わりかしやれた感を得られて楽しかった。
そもそも自分はハッカソンやらみたいな限られた時間で精一杯やるってのが好きなので、全力で走った後の心地よい疲れがたまらんですね。
珍しくブログ書くぐらいには楽しかった。