入社2年目で
大規模なデータベースの
アップデートを担当し、
大幅なコストダウンに貢献

入社3年目の今は『スタディサプリENGLISH』のSREとして、インフラ構築やモニタリングに従事しています。具体的には、他チームからの「こんなものを作りたいんだけど、インフラはどうすれば？」といった相談に乗り、必要なインフラを構築・管理するという仕事です。主にTerraformやAWS（Amazon Web Services）、Kubernetes、DataDog などを使い、またサーバサイドがScalaで実装されていることからJVM（Java Virtual Machine）のチューニングなども行っています。
初めて『スタディサプリENGLISH』チームと出会ったのはインターンシップで、当時AmazonのECS（Elastic Container Service）からEKS（Elastic Kubernetes Service）へとコンテナ基盤を総入れ替えしているのを目にして「技術的になかなか面白そうな職場だな」と感じました。 また、自社サービスを扱っているため「もっとこうした方がいいんじゃない？」といった自分の提案がプロダクトに反映されやすいことも魅力的でした。そして社会課題の解決に興味を持っていたことも決め手となり、リクルートに入社しました。
配属後はAtlantis導入に4ヶ月ほど従事し、その後1年間MySQLのメジャーバージョンアップデートを主担当として行いました。それが無事に成功すると、今度は半年ほどかけて本番環境へのSpot Instance導入を進めました。従来は起動したら原則好きなだけ使えるOn-Demand Instanceを使っていたのですが、コストを削減すべく、On-Demand Instanceの余剰キャパシティを安価に使えるSpot Instanceに切り替えたのです。Spot Instanceを使うとキャパシティの兼ね合いで、突然サーバが終了してシステムが不安定になる可能性があるため、冗長性を持たせるなど十分に対策してから本番環境に導入しました。現在は、新サービスのフィジビリティを行うためのインフラを構築しています。

特に印象に残っている案件は、入社1年目の末にアサインされた、MySQLのメジャーバージョンアップデートです。Aurora MySQL 2.x 系（MySQL 5.7 互換）のサポートが終了するため、Aurora MySQL 3.x 系（MySQL 8.0 互換）にアップグレードするというものです。何か問題が起こったらサービス全体に影響してしまう、比較的リスクの高い案件でした。
この案件の必須要件は、アップデート後もサーバがピークタイムの負荷に耐えられることと、サーバの動作が変化しないことでした。そこでまずは既存の負荷試験ツールを使って検証を行ったのですが、微妙にうまくいかなくて。そのツールは実際のタイムスタンプを考慮せず、時間を空けずにクエリを実行するだけのものだったんです。となるとツールとデータベースのどちらが悪いのか分からなかったので、問題を切り分けるために負荷試験ツールの自作から始めました。『スタディサプリENGLISH』のデータベースでは約98%がReadのリクエストなので「いったんReadを優先的に考えよう」と判断して、 General Query LogでMySQLでの実行ログを全てファイル出力し、それらを負荷試験側のインスタンスに持っていって時系列を追うように同じクエリを再現するというツールを作りました。似たようなツールは一般製品にもあるのですが、ユースケースが合わなかったり、想定アクセス量を細かく調整できなかったりしたので、自作したわけです。この自作ツールによる試験の結果、従来と同じCPUやメモリ構成のままアップデートすると、負荷には耐えられないことが判明しました。
そこで、いくつかの施策を実施しました。まず、従来から使用していたIntelのCPU（Central Processing Unit）ではなく、AWSが独自に設計したGravitonというCPUに替えました。演算精度やデータ読み書き速度の面で高性能だと聞いていたので、パフォーマンスを上げるための試行錯誤の一環として取り入れてみたところ、たいへん効果的だったのです。また、ストレージの設定もI/O-Optimizedというオプションに変更して実験したところ、スピードがさらに上がったので、こちらを採用することにしました（このオプションはRead / Writeが固定価格なので、『スタディサプリENGLISH』のようなRead / Write多めのワークロードでは、コストダウンにもつながりました）。
また、サーバチームにお願いして、一部のAPIでReaderインスタンスを使うように変更してもらいました。一般的にデータベースサーバは、読み書き両方ができるWriter Instanceと読み取り専用のReader Instanceの2台で構成し、2台のサーバを裏で同期させるのですが、ただ2台にするだけではWriter Instanceが優先されてReader Instanceが使われません。そこで、読み取りだけだがデータベースに負荷のかかる処理はReader Instanceを参照するように変更し、2台の間で負荷を分散できるようにしました。
これらの施策によってパフォーマンス悪化のリスクをクリアできたので、深夜メンテナンスで一度サービスを止めて、アップデートを実施しました。滞りなく終わり、翌日の朝になっても障害は起こらなかったため、安心して二度寝したことを覚えています（笑）。その後も二週間ほど見守っていたのですが問題はなく、アクセス量が増えた際も負荷試験でシミュレートしたのと同じようなカーブを描いていて「これ凄いな」と少し感動しました。

話は本番リリースの前に戻るのですが、前述のパフォーマンス向上施策は、ただアップデートを成功させるだけにはとどまりませんでした。施策を打ってから再度テストしてみると、なんとCPUが半分も余ったのです。「じゃあ、インスタンスサイズも一段階下げられるんじゃないか？」という感触がありました。
インスタンスサイズをひとつ下げると、CPUやメモリのサイズも半分になるので、かなりリスクが大きいです。しかし一方で、データベースのランニングコストも半分に減らすことができます。インフラのなかで一番コストがかかっているのはデータベースですし、コスト削減はそのまま事業利益に反映されるため、SREの仕事においては最も可視化されやすい事業貢献の形だともいえます。リスクが大きいとしても、挑戦する価値があると考えました。
そこで、インスタンスサイズを据え置いた場合と下げた場合のパフォーマンスについて負荷試験で入念に比較検証してみると、大きなレイテンシの差は出ず、サイズを下げても問題はないという確信を得られました。このような検証結果を整理し、メリットとあわせて開発サイドとビジネスサイド双方に丁寧に説明したところ、これまで前例のなかったサイズ削減の施策にもかかわらず、最終的に承認をもらうことができました。結果としてこの案件では、問題なくMySQLをアップデートするだけでなく、『スタディサプリENGLISH』のデータベースのランニングコストを半分に減らすことにも成功しました。

この案件はリスクが大きく明確な締切もあるため、まさか当時まだ入社1年目だった自分がやることになるとは思ってもいませんでした。上司は「サポートするから、主担当でやってみたらどう？」と言ってくれて、進捗に問題がないか定期的に確認してくれたり、プロジェクトの立ち上げや推進の仕方について相談に乗ってくれたりしました。そのうえで、大事な案件にもかかわらず大きな裁量をくれました。
そのため僕は、ただ要件通りこなすという形ではなく、ゼロから自分で考えて進めることができました。例えば何の検証から手をつけ、何をどう改善すればリスクを排除できるのかといったことは、全て自分で考えて道筋をつけていったのです。過去事例の資料を参考にしつつ、 ISUCONなどで培ったパフォーマンスチューニングの知識・経験を総動員して挑みました（注：『ISUCON』は、LINEヤフー株式会社の商標または登録商標です）。アップデートに伴う微妙な挙動の変化などは、AWSのサポートに問い合わせながら調査することもありました。
このように自分でいろいろ調べながらやりきるのは大変でしたが、その分やりがいもありましたし、インスタンスタイプやストレージの設定など自分でチューニングできる要素も多かったので面白かったです。新人にこそ大きな仕事を任せる、というリクルートの文化も体感できました。
また、自分のやりたいことを尊重してもらえるのも、リクルートだからこそだと思います。もちろん、ただなんとなく「できそうなのでやりたいです」というのでは通らないですよ（笑）。でも、ちゃんと事実に基づいて説明すれば、今回のように前例がなくリスクのある提案でも、ゴーサインを出してくれます。やりたいことがあれば声を上げるべきだということを学びました。
それにこの案件では、最初に感じた「なんとなくいけそうだ」というふわっとした仮説をきちんと検証し、周りの人たちに伝わるように説明をして、最終的に実現まで持っていく、というプロセスもとても勉強になっていて。こうしたプロジェクトマネジメントの分野はまだあまり得意ではないのですが、僕の上司や先輩はほんとうに上手だなと常々感じているので、これからもコミュニケーションの取り方や進め方を見て学んでいくつもりです。

入社1年目にもかかわらず大きな案件を任せてもらえたのは、データベースに詳しそうな雰囲気を出していたからかなと思います（笑）。普段からチーム内でも、言われたことだけをやるのではなく「こうすればもっと良くなるんじゃないか」と考え、自分からメンバーに発信するようにしています。また、サーバチームとの定例ミーティングのなかでも、サーバのチューニングやデータベースのパフォーマンス、クエリの書き方などに関する議論が行われるので、積極的にコメントしていますね。それに、ISUCONで上位に入ったり社内ISUCONで入賞したりという実績もあるので、「任せても大丈夫そうだ」と思ってもらえたのかもしれません（株式会社リクルート 社内ISUCON 2023についての詳細はこちら）。

SREとして日々の業務を行うなかで意識しているのは、障害の原因になりそうな問題を事前に察知し、早めに対処することです。と言うと当たり前のことのように聞こえるかもしれませんが、サービスのユーザーが多いため、こうした作業の要求水準は非常に高いです。本番環境に出す前に開発環境などで実験する、作ったものはDataDogなどで監視するといった基本的なことはもちろん、冗長性担保のためあえてステージングを壊しアラートを動作確認するといったこともしています。また、システムを構築・運用する際は正常系だけでなく、異常系をハンドリングすることも大事です。例えばデータベースに負荷のかかりそうな機能がリリースされたり、メモリリークを起こしているプロセスがあったりしたときに、その時点では壊れていなくてもちゃんと検知はして、サーバチームにフィードバックするようにしています。
でも、「こうすれば絶対うまく行きます」なんてものはないですよね。あったら苦労しません（笑）。だから、何か問題が起こってしまったときは、これまでの経験から得た勘をもとに、当たりをつけるようにしています。普段から「ここのサーバのプログラムはこういう処理をやっている」といった構造を把握しておくと、勘を養うことができるのです。そしてここがポイントですが、勘を勘で終わらせず、ログやメトリクスを見ながら事実確認をする。パフォーマンスチューニングにおいてよく言われる「推測するな、計測せよ」という言葉がありますが、なんでもかんでも勘でやるのではなく、問題の解消に移る前にちゃんと検証することが大事です。そうしてきちんと対処できたら、同じ障害を二度起こさないための仕組みを作っています。「今後気をつけます」といった人間の気合は脆弱なので、機械がミスを指摘してくれるような仕組みで解決するということですね。
これらはSREの「守り」の部分なのですが、保守的になり過ぎないようにも心がけています。 SREという仕事は障害を起こさないこと、つまりマイナスを限りなくゼロに近付けていくことが大前提ではあるので、どうしても「守り」を極め過ぎて、何も攻めない状態になってしまいがちです。でも、「攻め」た方が面白いんですよね。それに、システムを触っていると「今までより良くなりそうだ」ということが、例えばコストが下がりそう、開発者にとって便利になりそう、といったポイントが分かってしまうんです。前述のデータベースのインスタンスサイズを下げた件や、Spot Instanceを導入した件もそうですね。だから、システムを動かし支えてきたやり方には敬意を払いつつも「守り」過ぎないように、リスクを洗い出したり切り戻しを考えたりしつつ徐々に「攻め」ていくというバランス感を大事にしながらSREをしています。

SREの面白さは、「作ったら作ったようにしかならない」ところです。自分の行動とその結果が完全に一致するというか。どういう意味かというと、人間は指示を出せばうまく対応してくれることもありますが、逆に意図した通りにはいかないこともありますよね。一方、機械は命令したら命令した通りにしか動きません。だから問題が起こったらそれは全て自己責任だし、問題の原因もはっきりするから解決しやすいんです。単純に、不透明性や不確実性のない状態が好きなたちだというのもありますが。
ここでSREをやっていくメリットとしては、技術がモダンだという点があります。システムが非常に扱いやすいですし、学びも大きいです。リクルートにインターンシップに来たとき実感したのですが、モダンな技術の良さは、ある程度の規模で使わないと理解できない。例えばコンテナを使うにしても、個人開発の規模だと手動で事足りる作業が、サーバの台数が多かったり定期的にリリースする必要があったりするプロダクトとなると、自動化しなきゃ間に合わなくなりますよね。だからこそ我々も自動化の進んだKubernetesを使っているわけですが、こうしたモダンな技術を使いたい理由が分かっていないと、いくらモダンな技術を手段として持っていても、その恩恵を100%享受することはできません。逆に導入や学習のコストが上回る恐れさえあります。このように、大規模サービスのなかでこそ活きてくる技術を、背景や目的とセットで学んでいけるのは、リクルートならではかなと思います。

リクルートは技術だけでなく、人にも投資する会社です。メンバーの育成に関しても「そんなにやるんだ」と思うほど注力してくれますし、研修も充実しているので、入社後もちゃんと学びを得ることができます。研修はインフラの分野に限らず技術的なことは一通りやりますし、リクルートのビジネスモデルや、仕事をしていくうえで大事なスタンスなども教えてくれます（研修についての詳細はこちら）。
また、技術系のイベントの交通費や宿泊費などを、会社が負担してくれることもあります。例えば先日もラスベガスまで行って、re:InventというAWS主催の世界規模のカンファレンスに参加してきました。たくさんのセッションに加え、EBC（Executive Briefing Center）というAWSのエンジニアやプロダクトマネジャーなど専門家との議論の場もあり、現地ならではのコミュニケーションが取れて、普段の困りごとの解決策や今後サービスの参考にできそうなことなどを持ち帰ってくることができました。

技術が好き、というのは大事だと思います。趣味になるくらい好きだといいですよね。「お金を稼ごう」「技術力をつけよう」と思いながら取り組むのもいいのですが、「好きだから」という理由でプログラミングをする方が、結局は自然と技術力も高まる気がします。だから、仕事のなかで使われている技術を学生の段階で理解している必要はありませんが、学生のうちからがっつり技術に触れていろいろ取り組んでいる人と一緒に働けたら素敵だろうなと思います。そういう人と仕事ができるとコミュニケーションも捗るし、新しい技術の話題を持ち込んでくれるなど刺激にもなります。
但し、技術者だからといって技術のことしか考えないのではなく、事業がどうなっているのか気にすることも、エンジニアとして事業貢献するためには必要だと考えています。かく言う僕も入社当時はわりと技術に集中するつもりだったのですが、リクルートではエンジニアも「事業成長につながるか」「ユーザーの課題解決につながるか」を考える癖がついていて、僕の上司も事業的なメタ視点をすこぶる持っている人なので、僕も自然とビジネス観点にも目を向けるようになっていました。今では、案件では前述の通りコストなどを意識していますし、職種問わずの全体ミーティングで事業の現状をキャッチアップしたり、全社のIR資料を読んだりもしています。インフラチームはサービス規模の割に人数が少なく、サービス全体を俯瞰しやすい職種でもあるので、その利点も積極的に活かしていきたいですね。
今後のキャリアは「まだよく分からないな」というのが本音ですが、プロジェクトをまとめていく能力を養いつつ、やはり技術はずっと触り続けていきたいですね。リクルートにはシニアプロフェッショナルというスペシャリスト系の役職もあるので、そうした技術を極めていくキャリアパスも見据えつつ、得意なところを伸ばしていきたいです（エンジニアコースのキャリアパスについてはこちら）。

MY FAVORITE

LogicoolのMX MASTER

学生時代からこのシリーズを使っています。最初に購入したのはインターンシップをしていたころ、リモートワーク補助のような制度を通じて買ってもらいました。ジェスチャーなどを設定して便利に使っています。