自己紹介

―まずは自己紹介をお願いします。

フェニックス計画の全貌と下された使命

―フェニックス計画とは、具体的にどのような計画なのでしょうか？

【原】
出前館とLINEが資本業務提携を結び、出前館エンジニアとLINEエンジニアが一緒に仕事し始めたのが6月頃で、具体的にシステムを見始めたのは7月頃からなのですが、その頃から日に日に負荷が増加していっている状況でした。注文情報や店舗情報をOracle DBという1つのデータベースで管理しているのですが、すべてのアクセスに対してOracle DBへの問合せがかなり多くなってしまっている。アプリケーションとシステム構成上、DBへの問い合わせ数が多いためデータベースのCPU使用率が常に100％に近づいており、サイト自体が落ちかねないという状況が8月頃に予想されたんですね。

そのような状況の中で、年末にかけて、さらなる販促や広告を打っていくにあたり、耐えられるシステムの状態に近づけたいという相談をインフラチームから受けました。フェニックス計画とは、データベースの負荷軽減の実現を目指すプロジェクトです。

―背景としてシステムが注文急増に耐えられないという課題があったと。具体的にはどのように対応したのでしょうか？

【原】
簡単な図ですが、図（※図１）で説明しますと、フロントと呼ばれているところが、出前館のユーザーからのアクセスを受けるところだと認識してください。元々のリクエストが、オンプレミスのサーバーを経由してOracle DBにアクセスをしに行っていたという構成なのですが、ここへのアクセスをすべて受け入れてしまうと、Oracle DBのCPUが高騰してしまう。

それを解決するために、クラウドの別のDBをレプリケーションしたレプリカDBを作って、そこに対して参照系機能を、とくにOracle DBへの負荷を高めているであろうAPIを抜粋。APIによってロードバランサーで接続先を切り替えて、フェニックスに移行したAPIについてはレプリカDBを参照する。その他の更新系APIなどについてはロードバランサーから今までどおりのオンプレのサーバーに投げてOracleに行く仕組みにしました。

なので、APIのエンドポイントをここに定義してあげて、それによって振り分けるという感じですね。参照系の負荷を下げるデータベースにいくのはこっち、というのをロードバランサーで制御しています。

―問い合わせによって振り分けるということですね。ちなみに「フェニックス計画」の名前はどこから生まれたのでしょうか？

【原】
リポジトリ名を考えていて、経緯や意味合いは色々あるのですが、出前館システムを蘇らせるという意味も込めて、最終的にフェニックスという名前になりました。

フェニックス計画に立ちはだかった壁、そしてやりがいを感じた瞬間

―実際にフェニックス計画を実現する上で壁にぶつかることはありましたか？

【原】
プロジェクト・マネージャーとして、まず負荷を減らさなきゃいけないという課題は明確だったのですが、出前館のシステムをあまりわかっていなかったので、出前館システムを理解するところに非常に苦労したなあと覚えています。

【豊留】
最初、フェニックスのプログラムの構成とかプログラム寄りのアーキテクチャの選定というところに関わりました。言語は何にするか、フレームワークは何を採用するかとかです。Kotlinという言語が好きで当初はそれを検討していたのですが、出前館プロパーメンバーやLINEからの出向メンバー、外部のベンダーさんなど、開発に関わる方が非常に多いので、経験豊富なエンジニアがより多い言語を採用したほうがいいと判断しました。結局Javaを採用し、なじみ深いSpring Bootを選びました。トレンドや使いやすさより、より多くの開発者が集められる言語・フレームワークを採用するという判断が、悩んだというほどではないのですが、最初のポイントでしたね。

【山口】
Oracleが元々あって、このフェニックスは参照系を逃がすということで、AWSにDBを構築しました。Oracleとは別のDBで構築されたのですが、方言がOracleとは違うので、そこがまず辛かったのと、テーブル構造を変えられなくて、元のOracleから複製する形でレプリカDBにデータを流す際に、構造は全く変えられないので、問題があるテーブル構造のまま負荷を下げなきゃいけないっていうのが非常に苦労しました。元のテーブル構造を見直せればもっと早くなるのに、それはできないということで、そこが一番大変だったかなと思います。

【宇都宮】
このプロジェクトで一番大変だったのは、出前館の店舗一覧画面のデータを取得するAPIを、OracleからレプリカDBに移植するタスクです。API1本なのに開発工数が2か月くらいかかりました。11月終わり頃に着手して、当初の想定では、一番アクセス数の多いクリスマスに合わせるために、２～３週間でリリースする計画だったのですが、大幅にスケジュールが遅延して、結局1月中旬リリースになりました。山口さんの力を借りて二人月くらいかけてやっと1本が終わるとか、そんな感じだったので、作業ボリューム的に結構きつかったなと。

もう一点は、これも山口さんのものと関係するのですが、データベースのスキーマとかクエリとか、だいたい同じものを使っていたというのもあって、Oracleではある程度パフォーマンスが出ていたクエリをレプリカDBに移植すると、全然パフォーマンスが出なくて。Oracleだと1秒くらいで返せるSQLが、30秒たっても返ってこないとかそういうことがあったので、チューニングについてもかなり苦労したかなと。移植の作業量とパフォーマンスが苦労した二点です。

【小田】
このプロジェクトが新体制としてLINEからの出向メンバーと一緒に仕事をする最初の案件だったということもあって、スピード感や進め方などに慣れるまでがちょっと大変でした。APIの開発はそこまで大変ではなかったのですが、インフラのほうは初めて担当させてもらいまして。元々知識がなかったけれど今後つけていきたいところではあったので嬉しく楽しい半面、わからないことも多く大変でした。

【岡田】
私はOracleからレプリカDBへのデータの同期を担当していたのですが、個人的に初めての技術だったため苦労したのと、同期が参照APIとして本当に実用に耐えうるものになるのかという不安があって。本当にできるのかなって冷や冷やしながら進めていました。結果的に実現できましたが、もしできなかったら、皆さんにごめんなさいしなきゃいけないところなので、ちょっとビビりながら作業していたという感じですかね。

―逆に、やりがいを感じた面や、面白いと思った瞬間についてはいかがでしょうか？

【原】
PM観点になりますが、フェニックス計画が始まるまでは、出前館プロパーのチームの方と密接に関われることがなかったので、プロジェクトを通して関係性やワンチームの意識ができたことが大きいですね。このプロジェクトでは毎週インフラチームと対策という意味でミーティングを開いているんです。課題をお互いに洗い出して、じゃあ次どうしようかという計画をする。そこでインフラチームとの会話が生まれて、課題共有や対策をやっていけたのがよかった。プロジェクト完了後も定期的に相談などミーティングを続けているので、一緒に仕事をする上でワクワクします。いい時間ができてよかったなと思っています。

【豊留】
それまでオンプレ環境中心だったのがAWS環境をたくさん使うようになったり、今まではインフラを構築・設定する仕事は運用グループの方が基本的にやられていたと思うのですが、開発エンジニアもインフラに触れる機会がこのプロジェクトを機に一気に増えたなと思っていて、開発エンジニアが色んなものに携われる環境になったのが、すごくよかったと感じています。

【小田】
ワクワクポイントで言うと、インフラまわりなど「やりたいけどやったことがない」ことに、だいぶサポートをいただきながらも、たくさん挑戦させてもらえたことです。フェニックス計画に参画するタイミングが、このメンバー内では一番遅いほうで、始まってからやっとチームの一員になったというか、チームの輪が広がっていったというのが良かったなと思っています。

【山口】
AWS触れたのは良かったかなと思います。元々オンプレでやっていましたけど、今回はAWSにサービスを作ったので。業務で触るのが初めてだったので、楽しかったです。

【岡田】
LINEの開発の皆さんと一緒にできたのがすごく楽しかったですね。今までだったらポンチ絵を書いても「うーん無理だね」で終わってしまっていたことを、パワフルに実装していただいたので、あーすごいなと率直に感じましたね。こっちから何か言っても応答のスピードも早いし、圧倒されることのほうが多くて楽しかったですね。

【宇都宮】
このプロジェクトを通して1つのKPIとして、OracleのCPU使用率を下げるというのが至上命題としてあって、サービスが落ちるか落ちないかくらいの数字だったのが、今はかなり落ち着いてきていて、システムの障害についても、店舗一覧が高負荷で落ちてしまう事態もほぼなくなったので、開発の前後で目に見える成果があったのが面白かったと思います。

フェニックス計画を経てエンジニアもパワーアップ！

―今後また新たな課題が出てきたとき参考になる、フェニックス計画を通じて学んだテクニックや、ノウハウなどについてお聞かせください。

【原】
プロジェクトが終わるときにKPT振り返りでもあったのですが、技術負債を残さないことが大事だなと改めて感じました。出前館は長い年月、サービスを提供しており、実現したい機能を増築的に追加していくことは、ビジネスを加速させる上では大事だと思うんです。しかし、技術負債を返却する期間をちゃんと設けてプロダクトを成長させることが、後々の投資になります。いまやっている負荷対策もそうですし、技術負債を解消するために新たな技術を取り入れることで、プロダクトの成長に加えて、人のスキルも成長すると感じています。負債を定期的に解消していくことがプロダクトにとっていかに大事なのか、将来の投資になるのかということを、このプロジェクトを通して改めて学びました。

【豊留】
既存の出前館システムへの理解がものすごく深まったなと思います。このプロジェクトがきっかけで、既存のコードを隅から隅まで読みました。今の出前館のシステムがどうなっているのかとか、こうなったほうがいいな、というのがどんどん浮き彫りになってきて、次の新しいシステムを作るときにはこういう構成で、こういう実装で、みたいなアイディアがどんどん出てきているので、次につながる勉強になりました。

【宇都宮】
システムへの理解が深まったのも学びとしてあるのですが、出前館の店舗一覧画面って非常に巨大で複雑なSQLを使っていて、それを実用的な速度で動かすためにかなりチューニングをがんばる必要があったので、そのあたり、SQLチューニングなんかも前より自信を持ってやれるようになったのが、個人的な成長・学びとして良かったことかなと思っています。

【小田】
今までの出前館にないもの、自分の知識としてないものがけっこうあったので、スキル的なところで学びが色々ありました。リポジトリがGit系になったりとか、インフラ系ではAWSをTerraformで書いてみたりだとか。そもそもAWSのサービスというのをあまり知らなかったので、それぞれのサービスについて理解したという点は大きな学びかなと思っています。APIを移植するにあたって不要なコードが多かったのですが、可読性を落とすと不用意なバグを生み出すということを痛感したので、こういった修正のたびに積極的にメンテしていきたいと思っています。

【山口】
業務でAWSに触れたのが大きな学びです。趣味で触っているだけだと実績とは言えないですからね。古いものをリプレースするって大変だなと改めて思いました。だからこそ色んな業界でリプレースプロジェクトというのがあって、人がかき集められて、少しずつリプレースされているんだなというのを、身をもって体験した感じですね。 【岡田】インフラとアプリを一緒に改善すると効果が大きいと再認識しました。どっちかだけだと辛かったかなあと。やらなきゃと。DBがひっ迫しているって、DB側のチューニングだけではどうにもならない状況だったんです。今は本当に軽いというか効果が大きかったので、障害も減りましたし、インフラと運用を兼任しているのですが、運用の仕事がほとんどなくなるくらい楽になったので、ちゃんと夜寝られるようになりました（笑）

―プロジェクトを通して、システムとともにエンジニアの皆さんもパワーアップしたのですね。こうしたプロジェクトには、挙手したら参画できるものなのでしょうか？

【原】
積極性はウェルカムです。やりたいということに対して、やらないって言うことはむしろなくて、「いいよ、やりなよ！」と後押しするほうが多い気がしています。

【小田】
レガシーな出前館のシステムが、フェニックス計画を通じてモダンなシステムに近づいてきていて、今後も別のプロジェクトでどんどん刷新していく展望が見えているので、色々と学びが多い業務ができそうです。そういうモダンな環境での開発を求めてきても大丈夫なんじゃないかなって思っています。

【原】
レガシーなシステムをモダンな開発にもっていくことができる環境ではあるので、興味があればぜひジョインしてほしいですね！

　

※所属チーム名は取材当時のものです。