kariaの日記 @ Alice::Diary

kariaの日記 @ Alice::Diary

ノリツッコミの鳩子がはてなブログ書いちゃうよ

Kaigi on Rails 2024に参加してきた

Kaigi on Rails 2024のフォトパネル

SRE NEXT 2024に引き続き、Kaigi on Rails 2024にもオフラインで参加してきました。今年はオフラインの技術系カンファレンスへの参加を増やそうと思っておりまして、業務プロダクトでRailsに接しているだけにタイトルが気になるセッションが多く、実際収穫も多かったです。

セッション数がかなり多くて全部触れると無限に時間を消費していきそうなので、特に気になったセッションのみ感想を書いていきます。

DAY 1

RailsのPull requestsのレビューの時に私が考えていること

speakerdeck.com

RailsのcommiterによるPull Requestにマージされやすくなるコツの解説。他のあらゆるプロジェクトに適用できるわけではないでしょうが、「少なくともRailsはこうだ」という参考になるかと思って聞きに行きました。

特に強調されていたのが Real world use case? という部分。自分のユースケースとしてこのPRが活用できるのか、それが多くのユーザーに役に立つのか、という点が重要で、「技術的にできるからマージしてくれ」ではない、というのはなるほどと思った。あとは、絵文字が多すぎると組織票の可能性があるのでむしろ逆効果というのも「なるほど」ポイント。そんなに実現してほしければコメントを書きましょうと。

『Actual behaviorのところは否定文ではなく肯定文で書こう』というのもRailsに限らず文章書くときに意識しておきたいですね。「動きません!」では相手に何も伝わらない。

リリース8年目のサービスの1800個のERBファイルをViewComponentに移行した方法とその結果

speakerdeck.com

ViewComponentへの移行をサブプロジェクトでやり切ったという話。自動生成にして20万行の変更やりきったのものすごいし、そこからの段階的リリースがすごく丁寧なのが更に素晴らしいと思いました。

現実のRuby/Railsアップグレード

zenn.dev

Rails5.0からのアップグレード事例の紹介。アップグレードのやり方そのものはRailsアップグレードガイドに書いてあるので、そうではなくノウハウ的な部分が中心。テストがないとアップグレードしたとき壊れたかどうかわからないのでテストを書く文化を根付かせましょうとか、ビジネス側との良い関係構築を心がけましょうとか、かなり文化面での言及が多かった印象でした。確かに周囲の理解がないとアップグレードは難しい。

あとはこれね。

エンジニアの説明責任。「アップグレードの工数の許可がなぜ下りないの!?」とか現場の人は言いがちだが、そのための必要な説明と理解を得るというプロセスを、きちんと上の人がやってくれていますか?という話。文句を言うなという話じゃなくて、誰に対しても丁寧な説明が大事だよね、そういう動きをする人が必要だよねと思います。

DAY 2

都市伝説バスターズ「WebアプリのボトルネックはDBだから言語の性能は関係ない」

(資料未公開のようなので公開されたら埋め込みます)

朝イチから「RubyよりもGoのほうがISUCONにも勝ってるしベンチマークはいいよね」というなかなかロックな発表。とはいえ現実のWebアプリではDBのクエリ時間が支配的だし、スレッド数も絡んでくるし、N+1問題もあるし、適切なベンチマーカーを使ってパフォーマンスチューニングやっていこうぜという良い話でした。

Railsガイドにパフォーマンスチューニングの記事あるの知りませんでした。Railsガイド読むのマジで大事。

guides.rubyonrails.org

このIssueも読んでおきたい。pumaデフォルトの1プロセス5スレッドは多いよねという話。

github.com

推し活のハイトラフィックに立ち向かう Railsアーキテクチャ

speakerdeck.com

DAY2はとにかくパフォーマンスチューニングの話が印象強かったのですが、こちらの発表もそうでした。

このブログを読んでいる皆さんなら、チケット販売サイトがクソ重くなることを見越して販売開始時刻の数秒前ぐらいを狙ってリロードした経験とか、グッズ販売のサイトが重すぎてクレジットカードの決済が三回走ってあとから取り消してもらったりした経験とか、きっとあると思います(どちらも筆者の実体験です)。そういったエンタメ分野のトラフィックに対して真面目に立ち向かっているよというお話。

一体どんな凝った構成なんだろうとワクワクしながら見たのですが、意外なことにめっちゃシンプルな構成でした。

インフラアーキテクチャ

トラフィックを捌くときに下手にマイクロサービス化されていると、どこがボトルネックなのかを特定するだけでも一苦労になってしまうので、合理性はありそうです。きちんとCDNやRedisのキャッシュは入れているのでそのあたりで吸収はしつつ、AuroraやRails Appは事前に大きめにスケールしとくみたいな感じの戦略でしょうか。これで秒間8000リクエスト捌けるんだなあ。

参考になった部分としては、最近のMySQL/PostgreSQLで導入されている FOR UPDATE SKIP LOCKED でしょうか。これを使うことで「行ロックされている行をスキップする」というSELECT文が簡単に書けるということで、後述するSolid Queueでも使われているんだとか。これで数百RPS捌けるんだ!良いですね。

でも最後はRate limitを導入したという話で、やっぱそうなるか~というオチでした。外部APIはどうしようもない。

Data Migration on Rails

speakerdeck.com

Schema MigrationについてはActiveRecordに仕組みがあるけれど、Dataに関してはどうだ?というのがこのセッション。たとえばテーブルにカラムを追加したら初期値を埋める必要があるとか、別のテーブルをSchema Migrationで作成したので元々あったテーブルのレコードを移行するとか、そういうやつです。

感想としては、「代表的なアプローチ」の項目に5個も例が挙げられている時点で「やっぱり『これがベスト!』って言えるメソッドは無いよな~」と思いつつ、ruby-jp slackでアンケートを取ったりRedditで海外事情を調べたりと幅広く調査しているのがグッドでした。生SQLRails Consoleでの変更、やっぱよくないよね!!

Data Migrationを実現するgemの一覧

あとこのgemの一覧のスライドめちゃくちゃ笑った。皆さんgemのネーミングには苦労されている……。

ちなみにmaintenance_tasks gemのことをこのセッションで初めて知りました。これはData Migrationで利用できるかはともかく、管理ツールとして入れてみて良さそう。

github.com

Sidekiq vs Solid Queue

speakerdeck.com

Rails 8.0からデフォルトのバックグラウンドワーカーになるというSolid Queueが気になったので見に行きました。特にSidekiqから無理に移行する必要はなさそう(スループットや機能面ではSidekiqの方が優位)、ただ今から新規でrails newするときにRedis立てなくてよくなるというのがSolid Queueの便利な点だなといったところ。ありがたいまとめでした。

約9000個の自動テストの 時間を50分->10分に短縮 Flakyテストを1%以下に抑えた話

speakerdeck.com

自動テスト長いしよく落ちるし困る、なんとなく再実行したら通ったのでそのまま……というシチュエーションはまあよくある話で、それを地道に改善していったのは素直に拍手。改善を行った結果GitHub Actionsのコスト削減に繋がったという点も好印象ですね。

「これだけやればオッケー!」みたいな銀の弾丸はないけれど、改善したポイントを丁寧に解説して下さっているのは非常に参考になります。

WHOLENESS, REPAIRING, AND TO HAVE FUN: 全体性、修復、そして楽しむこと

speakerdeck.com

システムコンポーネントと設計のパターンを知るの、マジで大事!!などなど、頷くことが多かったです。なにかの設計をするときに、立ち戻って毎回読むようにしたいスライドでした。

一番共感したのはここ。

「楽しさにはビジネス価値があります」

「楽しく仕事をする」というのを最近かなり意識するようにしてて、同一の仕事のクオリティなら楽しくやれる方が絶対いい。全ての発表の最後の締めが「楽しさ」だったのが、本当にここに来てよかったなと思えた瞬間でした。

おまけ

最後にTwitter……じゃなかったXに上げた写真を何枚か置いときます。

今回の会場が有明セントラルタワーホール & カンファレンスという、東京ビッグサイト有明ワシントンホテルの間にあるビルの会場で、コミケ以外で有明に来るのがなんか不思議な感覚でした。

今回カンファレンス専用のWebアプリが提供されていて、PWAとしてiPhoneのホーム画面に置いておけば運営からのアナウンスがpush通知で飛んでくるというなかなか便利なアプリだったのですが、オープニングトーク直前のあたりでこんな感じに。 イベント時のハイトラフィック対応は本当に大変。

追記:トラフィックの問題じゃなくて「deploy後に放置しているとrequestがtimeoutするという現象が発生」していたそうです。ひい。

2日目終了後にRubyMusicMixin on Rails 2024というイベントに参加したときの一枚。楽しそうすぎる。

Amazon ECSにおけるnetworkMode,パブリックIPアドレス,VPC外部との通信可否を整理する

Amazon ECSにおいて、EC2とFargateそれぞれの場合にどういうネットワーク設定にできるのかすぐ忘れるので、早見表にした。

機能名 EC2 Fargate
networkMode: awsvpc 対応 対応
networkMode: bridge 対応 非対応
networkMode: host 対応 非対応
networkMode: none 対応 非対応
awsvpcにおけるパブリックIPアドレス つけられない つけられる

※表を簡素化するためOSがWindowsの場合は除外しLinuxに限定した。

networkModeをbridgeとかhostにしたタスク定義は、Fargateにそのまま持って行っても起動することができない。

注目ポイントとしては、ECS on EC2かつawsvpcを採用した場合にタスクにはパブリックIPアドレスを付与することができない。このため、タスクがLBを介さずにVPC外部(インターネット)と通信したい場合、プライベートサブネットにタスクを配置することとNAT Gatewayを設置することが必須要件となる。

このことはAmazon ECS開発者ガイドにも記載がある。

Amazon EC2 Linux インスタンスで awsvpc ネットワークモードを使用するタスクをホストする場合、タスク ENI にはパブリック IP アドレスが付与されません。インターネットにアクセスするには、NAT ゲートウェイを使用するよう設定されたプライベートサブネットでタスクを起動する必要があります。詳細については、「Amazon VPC ユーザーガイド」の「NAT ゲートウェイ」を参照してください。インバウンドのネットワークアクセスは、プライベート IP アドレスを使用する VPC 内からのものか、その VPC からロードバランサーを経由させルーティングされたものである必要があります。パブリックサブネット内で起動されたタスクは、インターネットにアクセスできません。

docs.aws.amazon.com

つまり、ECSタスクがLBを介さずにVPC外部と通信できるのかできないのかに着目して表にすると以下の様になる。

networkMode VPCサブネットの種別 EC2のタスク Fargateのタスク
awsvpc パブリック 外部通信できない 外部通信できる
awsvpc プライベート 外部通信できる 外部通信できる
bridge,host パブリック 外部通信できる (起動できない)
bridge,host プライベート 外部通信できる (起動できない)

パブリックサブネットにタスクを配置する場合、EC2とFargateでnetworkModeを別にしなければならない。あまりないかもしれないが、もしパブリックサブネットでEC2/Fargateが混在する環境ではタスク定義を別々にしなければならず不便を強いられる。パブリックIPアドレスは課金されるようになったことも考慮すると、基本的にはプライベートサブネットを利用するべきだろう。

SRE NEXT 2024に参加してきた

会場入ってすぐ横にあったフォトパネル

夏のSRE関連イベントオフライン参加するぞ祭り(自主開催)の最終回。2日間通しチケットに加えて、なぜか懇親会参加券も有りのフルセットを買ってしまいました。ぼっち参戦なのに懇親会どうするの……?

以下感想を書いていくのですが、行動順時系列で書くとかなりまとまりが無い感じになるので「印象に残ったセッション」「見られなかったけどチェックした発表資料」「懇親会」「スポンサーブース」の順にまとめて書いていこうと思います。

印象に残ったセッション

登壇資料まとめは以下の記事にまとまっています。2日目寝坊したりスポンサーブース回ったりした影響で、見ることができたセッション自体がかなり少なかったです。もっと見たかったなあ。

zenn.dev

工学としてのSRE再訪

speakerdeck.com

セッションの中で一番面白かった。すごく印象に残ったスライドが多いので一部引用させていただきながら感想書いていこうと思う。

SRE文脈における工学性

一番印象に残ってるのがこれ。いわゆる「運用に溺れてる状態」が左側で、技芸的というのは決して悪いことではない(と発表者の方も仰っていた)けれど、やはり長期的・持続的改善を考えていく上で目指すべき状態というのは右側でしょう。そう考えていくとSREというのはもっと工学的に解決ができるはずだよね?という風に自分の中で解釈しました。

そこから「工学思考に基づく(と思われる)代表的貢献の一部」としてチームトポロジーの紹介があったりとか(この後ほかのセッションでも触れられていたので買いました)。

あとは、「99.99%のトレースデータはゴミ」というアグレッシブすぎるタイトルの論文の紹介があったりとか(障害の発生前後のトレースデータだけ取ってあればいいよねという発想らしく、それはなるほど感)。

「Metastable Failure」もすごく納得感あった。「障害の根本原因はもう治したはずなのに、なーんか挙動不安定なままだよねえ?なんで?」ってなるあの現象のことね。

このように普段肌感で感じてることに名前が付くことの快感が詰まってて非常に面白かったです。もっと面白い論文いっぱいあるんだろうなあ。読んでみたいな。

巨大インフラ産業で戦うSRE

speakerdeck.com

オープンロジ、よくVTuberのグッズ買ったときに発送メールが来るのでお名前は存じ上げているけれど何のサービスかよくわかってないというところからセッション視聴。事業内容も興味深かったけど、それ以上にSREの一事例として興味深かったです。SREチームとしての取り組みが具体的かつ改善を実感できる内容なのがとてもよかった。

すごくよくある話。でも最近は「SRE」とか「Platform Engineering」とかセクションごとに名前がついてきたおかげで、いわゆる「インフラなんでも屋さん」のお仕事内容が分類しやすくなってきたこと自体は、いい時代になってきたよねと思うよ。

オープンロジラムネもらった

スポンサーブース行ったらラムネをいただいたのですが、開け方を完全に忘れててあたふたしました。

Enabling Client-side SLO

speakerdeck.com

Client-side SLOってなんだ?と思ったら、iOS/AndroidアプリへのDatadog SDK導入をSREが直接コーディングしたらしい。確かにClient-sideだわ。

LCPの75パーセンタイルという閾値、参考にしていきたいよね~~わかる~~という気持ち。

An Efficient Incident Response Training with AI

speakerdeck.com

AIが障害対応訓練のゲームマスターしてくれるんだって。なるほどね、これはもうGMレスのTRPGだな。

セッション翌日にスポンサーブースでツールのデモを見学させていただいたのだけれど、Slackでポコポコと障害対応指示が現れて(ランブックと呼ぶらしい)、あとからそのログを拾って時系列ドキュメント(ポストモーテム)を自動生成したり、それを共同編集したりできるそうで、インシデント管理ツールとしてかなり面白そうでした。インシデント管理していきたい。

見られなかったけどチェックした発表資料

このセクションは現在進行形で発表資料をチェックしている最中なので、後で増えていくかも。

プロダクト全体で取り組むSREing イシューから始める信頼性・生産性向上の実践

speakerdeck.com

イシューの見極め方の実例紹介。優先順位の付け方がこれだけ体型的に説明できると良いね。しかし、2019年に半年間新規開発をストップとか、Struts2のリプレースとか、事例がなかなかハードそうだ。

FourKeysを導入したが生産性向上には至らなかった理由

speakerdeck.com

「FourKeysはソフトウェアエンジニアのパフォーマンスを測る指標」「開発生産性を測るものではない」というところになるほど。LTのためあまり多くが語られていないのだけれど、(開発チーム自身ではなく)SREチームが主体となって開発チームの生産性を可視化したかった理由が気になるところでした。セッション参加して聞くべきだったなあ。

懇親会

1日目の終わりに会場を地下のクラブへ移動し、Cloudebaseさんの「CTOが趣味で作った」という佐渡島産のオリジナルクラフトビールで乾杯。アルコール度数7%と少し強めなIPA、かなり好みな味でした。

さすがに懇親会で話した内容は書けないけど、テーブル囲んでたまたま近くになった方とワイワイ話して、思ったよりかは楽しめました。「発表してくださいよ~」って言われたけど、ど、どうしようかな……。

スポンサーブース

今回スポンサーブースがかなり充実しており、全部回ってきました。

無料配布うちわの裏側がスタンプ帳のようになってて、スポンサーブースを回ってここにシールを集めると最後に抽選に参加できるよという仕組みがあってですね。特に知り合いもいないと「ブース行ったとて何話せばいいんだろう……」ってなりがちなのが、とりあえずシールを集めるという動機で話しかけることができるので良い仕組みだなと。

そもそもスポンサーブースって採用目的なんじゃ?という先入観があったのですが、ブースによってかなり趣向を凝らしていたし、結構話せるSREの方が多くて面白かったですね。ということで、印象に残ったブースのことを2つほど載せておきます。

CyberAgent

今回の会場提供もしているサイバーエージェントさんは、ただゲームの紹介とシステム構成図を展示しているだけという硬派なブースながら、「他所のシステム構成図ほと面白いモノはないじゃん!」と興味深く見させていただきました。帰ってから調べたら一部はこのスライドやブログなどに出ている内容で、一部は出ていない内容みたい(時期未定だけどそのうちブログに出るとか)。

speakerdeck.com

Aurora Serverless v2、ノーメンテでDBのスケールアップ/ダウンができるのすごい魅力的だな。スケールするときの瞬断はあるけどv1より時間も短くなっており、深夜帯なんかは勝手にスケールダウンしていくのでコストもそこまででもないらしい。最初大きめのスペックにしておいて、アクセスが落ちついて来たら徐々に最適化をかけていく流れがすごく理想的だなあ。

SMS

私「すいません~事業内容とか全然存じ上げてなくて……」
「いえいえ!ところで今『SREあるある缶バッジ』をお配りしてまして」
私「へえそうなんですね」
「好きなの1個選んでください!人気なのは『オブザーバビリティ』ですね」
私「うーん……じゃあこれで」

SREあるある缶バッジ

まとめ

最初は面白いセッションに何個か当たればいいや、ぐらいのつもりで申し込んでみたけど、蓋を開けてみればスポンサーブースも懇親会も思ったより楽しめたなという印象だし、セッションは分身して見に行きたいぐらい重複していた裏枠も見たい気持ちでいっぱいでした。

個人的反省点を挙げるとしたら英語のセッションが全然聞き取れず(同時翻訳があるものだと思い込んでいた)、スライドが日本語だったのでかろうじて雰囲気は掴めたが、やはり英語のリスニングが出来ないのは大きなマイナスだなあと痛感した次第でした。リスニングの勉強するか……?