地点検索の進化とDXを支えるリアーキテクチャ

2019年9月20日に開催された「ナビタイムの現場 第3経路 -ナビタイムを支える屋台骨-」にて発表した資料です

Transcript

1. 地点検索の進化と DX を⽀える 地点検索の進化と DX を⽀える リアーキテクチャ リアーキテクチャ
2. ABOUT ME ABOUT ME Yu Mochizuki @ NAVITIME JAPAN Co., Ltd. MY WORK MY WORK 地点検索の研究開発 全サービス共通 API 基盤開発 開発者向け検証サポート
3. MY CAREER MY CAREER 1. コア技術である経路探索エンジンの開発 2. B2B 事業 厳しい制約条件の中, 技術的負債に向き合い, DX の重要性に気づく. 開発リーダーを担当し, DX 重視の現場運営を実践. 3. バックエンドサーバ開発に そんな中で巡ってきたリアーキテクチャ案件が, 今⽇の話. ※ DX = Developer Experience ( 開発者体験)
4. SUMMARY SUMMARY 地点検索技術の発展を促すことを⽬的にリアーキテクチャに取り組み, 開発効率 や DX を改善した話.
5. AGENDA AGENDA 1. なぜリアーキテクチャが必要になったか 2. 共通 API 基盤からマイクロサービスへ 3. フルスクラッチリプレイス 4. DX First な開発ポリシー 5. リアーキテクチャ経験の副次的効果
6. なぜリアーキテクチャが必要になったか なぜリアーキテクチャが必要になったか
7. ナビタイムジャパンが⽬指すもの ナビタイムジャパンが⽬指すもの 経営理念 : 経路探索エンジンの技術で世界の産業に奉仕する ナビゲーションサービスにおける, 地点検索の⽴ち位置とは...
8. 地点検索が正確でないと ... 地点検索が正確でないと ...
9. 地点検索が正確だと ... 地点検索が正確だと ...
10. ナビゲーションサービスにおける地点検索 ナビゲーションサービスにおける地点検索 経路探索は 正確に⽬的地が選べなければ成⽴しない. 詳しく知りたい⽅は: 「安⼼な移動」のための POI 検索
11. ナビタイムの共通技術資産 ナビタイムの共通技術資産 経路探索を中⼼にいろいろな技術資産を持っており, 共通 API を通じて提供され ている.
12. 地点提供のはじまり 地点提供のはじまり もともとはシンプルなデータフェッチだったので, 共通 API チームが地点検索機 能を開発していた.
13. 地点検索のはじまり 地点検索のはじまり " もっとよく当たる検索を!" という要求が⽣まれ, SQL では限界を迎えたので, 全 ⽂検索システム (Solr) を使い始めた. ひとまず共通 API チーム持ちになった.
14. 地点検索の⾼度化 地点検索の⾼度化 " もっともっと正確で便利な検索を!" という要求から⽣まれ, 全⽂検索システムの チューニングが必要になった. 専⾨的になってきたので, 地点検索チームができた.
15. 検索 API の⾼度化 検索 API の⾼度化 地点検索の改善には, 共通 API サーバ上の機能が想像以上に重要だった.
16. 検索 API の開発 検索 API の開発 地点検索チームも, 共通 API を積極的に開発するようになった.
17. 課題 : リリースサイクルが合わない 課題 : リリースサイクルが合わない 共通 API サーバは多くの機能が相乗りしている (= Monorithic). 頑張って作った機 能がなかなか世に出せない.
18. 課題 : 複雑化した実装を改修するのが⼤変 課題 : 複雑化した実装を改修するのが⼤変 共通 API サーバは⻑年の運⽤で技術的負債が増えてきた. 難しい開発にチャレン ジしにくい. コードが複雑になり, 機能追加もテストも⼤変. フレームワークの作者もいなくなった.
19. 課題を解決するために 課題を解決するために リアーキテクチャに取り組むことに. マイクロサービス化 → リリースサイクルを独⽴させる. フルスクラッチリプレイス → 改修コストを下げる. そして, いい機会なので DX First に取り組んだ.
20. 共通 API 基盤からマイクロサービスへ 共通 API 基盤からマイクロサービスへ
21. マイクロサービスとは マイクロサービスとは アプリケーションを⼩さな独⽴したサービスの組み合わせによって実現するアー キテクチャ. クライアント サービス サービス サービス サービス ID プロ バイダー マイクロサービス API ゲー トウェイ リモート サ ービス 管理 CDN 静的コン テンツ サービス検索 https://docs.microso .com/ja-jp/azure/architecture/guide/architecture-styles/images/microservices-logical.svg
22. マイクロサービスが⽬指すもの マイクロサービスが⽬指すもの それぞれの機能を独⽴に, 専⾨的に発展させる. cf. cf. 今回は, 地点検索を共通 API と疎結合にして, リリースサイクルを独⽴させる. AWS による説明 Microso による説明
23. どこをマイクロサービス化したか どこをマイクロサービス化したか " 検索システムを正しく使う" ところを新規サービスに切り出した.
24. やらなかったこと やらなかったこと " 新しい I/F に移⾏させる" ことはしなかった. I/F 移⾏は⼤変だし, できなくても⽬標は達成できるので, 今回は我慢した.
25. マイクロサービス化の効果 マイクロサービス化の効果 リリースサイクルが共通 API から完全独⽴ → ⽬標達成！
26. おまけ : マイクロサービスと組織構成 おまけ : マイクロサービスと組織構成 今回は が⾃然に当てはまる事例となった. コンウェイの法則 Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. http://www.melconway.com/Home/Conways_Law.html
27. フルスクラッチリプレイス フルスクラッチリプレイス
28. 旧システムに敬意を 旧システムに敬意を 今までお世話になった共通 API に感謝の⼼を持つ. 動いているものこそ⾄上. どんなに恐ろしいコードでも, 価値を⽣んできたシステムの⼀部. ※ 冗談みたいだが本当に⼤事なこと.
29. 有識者の確保 有識者の確保 リプレイスにトラブルはつきもので, 意思決定がボトルネックになりがち. 地点検索を知り尽くした開発者とペアプロ中⼼で進めた.
30. 実装のモダン化 実装のモダン化 ほぼすべての Java コードを Kotlin で書き直し, 実装をシンプルにした. 例えば, 愚直な検索叩き直しロジックを... final Response response1 = client.execute(createQuery1()); if (response1.isSatisfied()) { return Optional.of(result1); } final Response response2 = client.execute(createQuery2()); if (response2.isSatisfied()) { return Optional.of(result2); } return Optional.empty();
31. Kotlin ( ) で書くと, 興味が分割されて simple & testable に. ※ ポイントはクエリ⽣成が遅延評価されること. Java で真似するとここが⼤変. Sequence val queries = sequence { // 抽象化 testable . yield(createQuery1()) yield(createQuery2()) } return queries.map { client.execute(it) } .firstOrNull { it.isSatisfied() }
32. サードパーティフレームワークへ サードパーティフレームワークへ 内製フレームワークを捨て, 利⽤実績豊富な を利⽤. 実装するより, ググる コードが減るのでバグも減る Spring Framework
33. ⾃動テスト ⾃動テスト 開発中のデグレードを防ぐため, ⾃動テスト整備は特に優先した. C0 98% の単体テスト 全⾃動 API テスト : YAML で書ける Web API テスト. Preacher
34. モニタリング モニタリング 運⽤して初めて分かる問題を拾うため, モニタリングを整備した. ※ メモリリーク発⾒
35. リリースゴール設定 リリースゴール設定 新旧差分確認ツールを活⽤し, ゴールを検証可能にした.
36. フルスクラッチリプレイスの効果 フルスクラッチリプレイスの効果 ⼯夫の甲斐あって, つつがなく完了. あっという間に投資を回収でき, 開発効率の改善を実感 → ⽬標達成！
37. DX FIRST な開発 DX FIRST な開発
38. DX の重要性 DX の重要性 プロダクトを継続的に育てるためには, 開発者が楽しいと思えることが理想だと 考えた. 開発者が⾃然と定着する 開発者がスキルアップする
39. DX と技術的負債 DX と技術的負債 開発者の感情は, 技術的負債に敏感に反応する. やりたい -> 効率を上げるための投資 いやだ -> 効率を下げる負債の兆候 技術的負債の程度は, 開発者の感情で測れるのでは?
40. WHY DX FIRST? WHY DX FIRST? プロダクトを育てる⼈を, 継続的に育てる 技術的負債のプライマリバランスを保つ これを実現するために, 開発者が楽しいと思うこと を優先的にやる. 開発者の勘に任せた結果, プロダクトの価値が最⼤化される.
41. DX FIRST の⼤前提 : ⼀流の開発者であり続ける DX FIRST の⼤前提 : ⼀流の開発者であり続ける 開発者の感性が鈍かったら良い⽅向に進むはずがない. → を → に近づける判断ができるようになる.
42. DX FIRST を守るために DX FIRST を守るために 強権を発動され, 短期的に成果を過剰に要求されることが最⼤の懸念. 信頼が厚いメンバを揃えた. ちゃんと終わりそうな案件規模にした. ほかの業務を続けて, 成果を出し続けた.
43. FOR DX: リアーキテクチャ FOR DX: リアーキテクチャ 今回のリアーキテクチャ⾃体が, DX を向上させた. 気楽にリリースする キレイなコードにふれる モダンな技術にふれる
44. FOR DX: テスト・モニタリング FOR DX: テスト・モニタリング バグを恐れず開発するため, テストとモニタリングは特に⼤切にした. デグレードしたらテストで気づく. 万が⼀本番で問題が発⽣しても, モニタリングですぐ気付ける.
45. FOR DX: 構成はシンプルに FOR DX: 構成はシンプルに 本質的な問題に集中するため, 徹底的してシンプルさにこだわった. Clone 即起動. 全機能がローカルで使える. 単⼀ JAR で運⽤.
46. FOR DX: イベントトレース FOR DX: イベントトレース ブラウザだけでデバッグできるように, 外部リクエスト等をトレース. { "items": [ ... ], "_debug": { "externalActions": [ { "url": "https://external.com/api?word=%E6%9D%B1%E4%BA%AC", "params": { "word": "東京" } } ] } }
47. FOR DX: エラートレース FOR DX: エラートレース ブラウザだけでデバッグできるように, 発⽣した例外をトレース. { "code": 503, "message": "A backend service is not available now.", "_debug": { "exception": { "message": "External API returns status code 503.", "stacktrace": [ "jp.co.navitime.foo.ExternalApiClient.kt:123", ... ] } } }
48. FOR DX: 外部リクエスト強制遮断 FOR DX: 外部リクエスト強制遮断 実際にバックエンドを異常にするのは⾯倒. 強制遮断機能を実装. ※ 危なすぎるので, もちろん本番では無効化. $ curl https://spot-search.com/circuit/solr/failure?count=20
49. 結局 , DX FIRST とは 結局 , DX FIRST とは 楽しいこと = やりがいがあること. 基本に忠実に, ストイックに, 技術で解決すること こそが, エンジニアの楽しみ.
50. DX FIRST の効果 DX FIRST の効果 新たに join したメンバの感想 機能追加不安だけどテストが書けるので安⼼して進められそう. これ読んでいたおかげで検索システムの⾼速化頑張れそう. モブプロで解説聞いてる間の⼼境は SW EP4 のミレニアム・ファルコン号でル ークがブラスターをライトセーバーで跳ね返す訓練してる時のそれ.
51. リアーキテクチャ経験の副次的効果 リアーキテクチャ経験の副次的効果
52. 共通 API 基盤のリアーキテクチャを加速 共通 API 基盤のリアーキテクチャを加速 本案件は共通 API チームにヒントを与えた. リリースサイクルや複雑さに懸念のある技術要素に対し, リアーキテクチャの機 運ができ, 実際に案件もスタートした.
53. 共通 API 基盤の技術⾼度化 共通 API 基盤の技術⾼度化 新しい⾔語やフレームワークの知識を得たことで, 共通 API サーバを⾼度化する アイデアが⽣まれた. たとえば, Spring AOP にインスパイアされて AspectJ を導⼊し, 数千⾏のコードを 削減した.
54. ⾃⾝のキャリアアップ ⾃⾝のキャリアアップ 開発者検証の抜本的な⾒直しを経験したことで, ⾃⾝の SET (So ware Engineering in Test) エンジニア としてのキャリアを開拓した. 現在は, このリアーキテクチャの中で培ったテストやモニタリングのノウハウを, 社内で啓蒙する活動や, 技術⽀援をしている.
55. まとめ まとめ 実りの多いリアーキテクチャが実現できた. マイクロサービス化 → リリースサイクル改善 フルスクラッチリプレイス → 開発効率改善 DX First → 楽しく継続的に開発できるプロダクト ⾃⾝や周囲への好影響