Shoeisha Technology Media

CodeZine(コードジン)

特集ページ一覧

Yahoo!カレンダーがPHPからKotlinに技術移行し品質アップ! 成功の鍵とは?【デブサミ2018 関西】

【A-4】なぜYahoo!カレンダーはPHPからKotlinへ技術移行を進めるのか

  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加
2018/10/23 14:00

目次

インフラは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の認証形式
Athenzの認証形式

 Athenzは、IPに依存しない、ホストごとにロール登録が不要でスケールしやすい、他のインフラに依存しないといった特徴を持つ。OSSとして提供されており「GitHubで公開しているので、興味のある人はぜひ使ってほしい」と岡田氏は話した。

 続いて言語をPHPからKotlinに変更した理由について語った。まずPHPの課題として、システム全体で見たときに、コードの可読性が低く挙動の把握がしづらい点があった。また、実行時ではなくコンパイル時にエラーに気付きたい、可能な限り静的な解析や型を導入することで最低限の品質を担保したいことを考慮して、Kotlinへの移行を決断した。

 「最後までGoと悩んでいた」と岡田氏。Kotlinに決めたのにはいくつかの理由がある。まずは最低限の規律ができること。「Kotlinは型が厳格でコードの挙動も把握しやく、Sealed classなどの制約もかけやすい。IDEの強力なサポートもあり、振る舞いに問題があるとエラーになるので意図しないミスも防げる。しかも型推論があるので冗長にならず簡略に書けて便利だ」(岡田氏)。

Sealed Classによる制約例
Sealed classによる制約例

 次に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



  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加

修正履歴

  • 2018/10/26 11:06 2ページ目、「RBAC(ロールベースアクセス制御)システム」について情報を追記しました。

著者プロフィール

バックナンバー

連載:【デブサミ2018 関西】セッションレポート
All contents copyright © 2005-2019 Shoeisha Co., Ltd. All rights reserved. ver.1.5