「ユーザーのための時間」を増やすため技術移行を決意
Yahoo! JAPANが提供するサービスの1つ「Yahoo!カレンダー」は、2000年にWebのサービスとして提供を開始。2005年、2012年、2014年、2016年と画面デザインの変更や機能追加などのリニューアルを繰り返してきた。一方、アプリは別プロダクトとして2015年にリリース。2017年にWeb版とアプリが統合した。「Yahoo!カレンダーアプリは累計800万ダウンロードを達成。月間アクティブユーザー数も昨年と比べると140％の成長を遂げるなど、年々成長を続けているサービス」だと岡田氏は説明する。
サービス開始から18年。「これだけ長いと技術的な負債を抱えてしまう」と岡田氏。実際に、サーバーサイドでは次の課題を抱えていたという。第一に、アプリケーションが細かく分割されすぎて修正コストが高くついていたこと。「機能を1つ追加しようとすると、AとBとCも変更しなくてはならなくなり、どうしても工数が膨らんでしまう。なかなか新しい機能が提供できない状況に陥っていた」と岡田氏は明かす。
第二にPHPのアプリでフレームワークを使っておらず、個別の実装が多かったこと。「年季の入ったコードも多く、コントローラーの動きが違うなどの問題があった」と話す。第三はスケールが簡単にできないこと。第四は運用面でのコストが増え続けることだ。「このままでは安定してユーザーに価値提供ができなくなるのでは、と考えるようになった」と岡田氏は話す。
岡田氏が言う価値とは、プロダクト面で言えば圧倒的な簡単さや心地よさを指す。サーバーサイド面での価値とはユーザー体験を支えるスループットとレイテンシーが担保されること、およびユーザーが増えても安定して稼働することである。Yahoo!カレンダーサービスを提供する限り、「（予定が外に）漏れない、（予定が）消えない、止まらない」を守り切らねばならない。これらの課題を解決するため「改めて技術を再検討しようという流れになった」と岡田氏は振り返る。
チーム全員が集まり、ゴールのセッティングを行った。その際に大事にしたことが2つある。まず技術移行は目的ではなく手段とすること。あくまでゴールはユーザーの時間を最大化することである。次に、チームで話し合い、自分たちの考えを言語化することだ。
技術移行をする目的の第一は、システムのための作業時間を削減し、ユーザーのための時間を大きくすることである。第二に、場当たり的に対応することが多かったところを、少し長い目で考えられるようにすること。第三は前向きな選択ができるようにすること。つまり「もっと多くの人に価値提供を続けていくための戦略的選択ができるようにすること」が技術移行を進める理由だったと語る。
どの技術に移行するべきかについては、組織の状況が関わってきた。2000年にサービスが開始された当初の拠点は東京のみ、3人でチームを組んで開発をしていた。現在は東京2カ所に加え、大阪、ベトナム・ホーチミンの計4カ所、20人でチームを組み開発を行っている。大きくなったのは組織だけではない。システムも拡大していた。そのため「過去の最適解が今の最適解ではなくなった」と岡田氏。また拠点が分かれていることや、メンバーが増えたことによって、自分が当たり前だと思っていることが他のメンバーに伝わっていないこともあったという。こういった状況下で一定のレベルを担保するためにも「言語やフレームワークなど、システム的な制約を設けたい、そしてインフラもより課題に合ったスケールしやすい環境に変えていきたい、という思いが高まった」と岡田氏は力強く語る。
こういったポイントを踏まえ、現行の「OpenStack＋Apache Traffic Server＋PHP（一部Java）」といった構成から、インフラ部分をKubernetesやOSSのPaaS基盤であるCloud Foundryに、言語はKotlinに変えていくことに決めたのである。
インフラはPaaSとKubernetes、言語はKotlinを選定したワケ
従来のインフラの問題点は、スケールが簡単にできないことと運用面でのコストが増え続けることである。現行のシステムは、ユーザーからのリクエストをGSLBが受け、新白河と北九州データセンターにリクエストを振り分ける。そこからセキュアネットワークに流し、アプリケーションで処理する構成となっている。こういった構成でVMを1つ作成する場合、Chefで環境構築し、セキュアネットワークに流すためL4のレイヤーで認証設定後、VIPでサービスに追加することになる。
「この作業を毎回行うのが、私たちにとっては手間だった。CaaSはコンテナまで、PaaSではミドルウェアやランタイムまで管理してくれる。マイクロサービスにうまくできていない部品を制御しやすいインフラとして、KubernetesやCloud Foundryに移行することに決めた」（岡田氏）
そのほかにも、オートスケールを活用することでスケールアウトしやすい点や、オートヒーリングを使えば、VMや物理的なサーバーでもすぐに復旧できる耐障害性の高さも、これらの技術選定の決め手になったという。
L4での認証をどうしたのかは気になるところだ。というのも、コンテナ技術を使うとIPは毎回変わるため、IPベースの認証はできなくなる。だが適切なリソースの管理は必要になるため、L7のアプリケーションでオーセンティケーションやオーソリゼーションといった認証をするように切り替えているという。そこで今回、活用しているのがAthenzというOSSである。これは旧Yahoo! Inc.（現Oath）が開発したRBAC（ロールベースアクセス制御）システム。Yahoo! JAPANも開発に参加している。岡田氏は、この認証形式についても簡単に紹介した。図を見ればわかるとおり、Service単位でアクセスを管理し、トークンを用いて認証をするものだ。
Athenzは、IPに依存しない、ホストごとにロール登録が不要でスケールしやすい、他のインフラに依存しないといった特徴を持つ。OSSとして提供されており「GitHubで公開しているので、興味のある人はぜひ使ってほしい」と岡田氏は話した。
続いて言語をPHPからKotlinに変更した理由について語った。まずPHPの課題として、システム全体で見たときに、コードの可読性が低く挙動の把握がしづらい点があった。また、実行時ではなくコンパイル時にエラーに気付きたい、可能な限り静的な解析や型を導入することで最低限の品質を担保したいことを考慮して、Kotlinへの移行を決断した。
「最後までGoと悩んでいた」と岡田氏。Kotlinに決めたのにはいくつかの理由がある。まずは最低限の規律ができること。「Kotlinは型が厳格でコードの挙動も把握しやく、Sealed classなどの制約もかけやすい。IDEの強力なサポートもあり、振る舞いに問題があるとエラーになるので意図しないミスも防げる。しかも型推論があるので冗長にならず簡略に書けて便利だ」（岡田氏）。
次にSmart Castやdata classが便利、IDEのサポートが強力で高い利便性があること。第三はJavaのエコシステムが使えることだ。「これまで積み重ねてきて得られた巨人の肩に乗れることは大きかった。これが一番の決め手だった」と岡田氏は明かす。
フレームワークについては、「基本的にJavaのものを使っている」と岡田氏。Spring Frameworkはv5からKotlinをサポートしており、またSpring Bootも使えるので導入コストも低いという。Kotlin向けのフレームワークも登場しているが、例えばSpring Fuだけでは事足りない場合があると話す。
実際にYahoo! JAPANで活用しているのは先述のAhtenz（認証/認可）や、Pulsar Client（MQ）、Hystrix（サーキットブレーカー）といったJavaライブラリと、Spring Boot（フレームワーク）、MVC、Batch、Moshi（Jsonパーサー）といったKotlin対応のJavaライブラリだ。
Kotlin対応とは、Kotlinらしく書けるということ。Kotlin対応でなくても動かないわけではない。ただごくまれに言語特有の部分で意図しない挙動になる場合があるので、留意する必要があるという。
言語の移行にはメリットだけではなくデメリットも当然ある。とはいえ、岡田氏がデメリットとして挙げたのは、学習コストがかかること程度。「現移行でつまずくことはなく、ハードルは高くはなかった」と言い切る。それよりも言語面での仕様や制約をうまく使うことで、全体での品質向上につなげることができ、生産性も高まっているという。またチーム内のメンバーから「開発が楽しくなった」との声も多く聞かれた。「新しい言語を採用した身としてはすごくうれしい反応」と笑う。
今後のチャレンジについても語られた。現在、システムについては部分的にPHPをKotlinに移行中だが、「後々はJavaの部分もKotlinに移行したいと考えている」と岡田氏。またインフラについては、Istio、Envoyを使ってカナリアリリース可能な環境の構築を目指していくという。
こういった技術移行を実現するために、チーム作りにもこだわった。「価値あるコミュニケーションにはコストをかけた」と岡田氏。20人全員が東京に集まって議論することもあったという。またお互いを知るためにメンバー間の1on1、チーム全体でお互いの期待値合わせをするためにドラッカー風エクササイズを実施した。そのほかにも、4拠点で毎日朝会を行い顔を合わせる場を設定し、ペアプログラミングや、全体の開発力・知識レベルの底上げのためのハンズオンを実施するなど、工夫を重ねている。
「技術だけではなくチーム作りも並行して行い、前向きな選択ができる強いエンジニアリング組織にしていく。こうすることでチーム全員が同じ方向を見て走って行ける」
最後に岡田氏はこう語り、セッションを終えた。
お問い合わせ
Yahoo! JAPAN
