Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
なぜYahoo!カレンダーはPHPからKotlinへ技術移行を進めるのか
Search
BulBulPaul
September 28, 2018
Technology
3
5.8k
なぜYahoo!カレンダーはPHPからKotlinへ技術移行を進めるのか
Developers Summit 2018 Kansaiで発表したYahoo!カレンダーのサーバーサイド技術移行に関して。
BulBulPaul
September 28, 2018
Tweet
Share
More Decks by BulBulPaul
See All by BulBulPaul
AWS Updates - App Dev & AI/ML -
bulbulpaul
0
140
re:Invent re:Cap / AWS Lambda Updates
bulbulpaul
1
330
ぼくたちは Java アプリケーションの起動速度をどこまで縮められるか
bulbulpaul
14
8.5k
あらためて、AWS SDK for Java 入門
bulbulpaul
2
1.1k
AWS SAMを使ったIaC and CI/CD
bulbulpaul
4
3.6k
サーバーレスAPIをKotlinで開発してみよう!
bulbulpaul
0
990
KotlessではじめるServerlessアプリケーション開発
bulbulpaul
0
630
Micronaut で始める Server Side Kotlin
bulbulpaul
5
1.7k
Kotlin v1.3 Features
bulbulpaul
1
230
Other Decks in Technology
See All in Technology
VPC Latticeのサービスエンドポイント機能を使用した複数VPCアクセス
duelist2020jp
0
180
GitHub Copilot coding agent を推したい / AIDD Nagoya #1
tnir
2
4.5k
広島発!スタートアップ開発の裏側
tsankyo
0
240
Devinを使ったモバイルアプリ開発 / Mobile app development with Devin
yanzm
0
180
ドキュメントはAIの味方!スタートアップのアジャイルを加速するADR
kawauso
3
340
KiroでGameDay開催してみよう(準備編)
yuuuuuuu168
1
130
実践アプリケーション設計 ③ドメイン駆動設計
recruitengineers
PRO
1
160
ECS モニタリング手法大整理
yendoooo
1
120
LLMエージェント時代に適応した開発フロー
hiragram
1
410
[OCI Skill Mapping] AWSユーザーのためのOCI(2025年8月20日開催)
oracle4engineer
PRO
2
140
Evolution on AI Agent and Beyond - AGI への道のりと、シンギュラリティの3つのシナリオ
masayamoriofficial
0
170
制約理論(ToC)入門
recruitengineers
PRO
2
260
Featured
See All Featured
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
23
1.4k
RailsConf 2023
tenderlove
30
1.2k
Documentation Writing (for coders)
carmenintech
73
5k
Building a Modern Day E-commerce SEO Strategy
aleyda
43
7.5k
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.5k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.5k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
890
The Invisible Side of Design
smashingmag
301
51k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
283
13k
Rails Girls Zürich Keynote
gr2m
95
14k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
31
2.2k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4k
Transcript
Developers Summit 2018 Kansai 2018/09/28 なぜYahoo!カレンダーは PHPからKotlinへ技術移⾏を進めるのか ヤフー株式会社 おかだ のぶお
@bulbulpaul
˞:BIPPΧϨϯμʔΞϓϦͷྦྷܭμϯϩʔυʢ݄ूܭ࣌ʣʹͳΓ·͢ɻ
!3 すべての⼈の「今から」を より楽しく、より有意義に ࣸਅ: Ξϑϩ サービスビジョン
!4 カレンダーの拠点 Ho Chi Minh ⼤阪 東京 / 紀尾井町 東京
/ 豊洲 ⾼知 • 国内4拠点 • 国外1拠点
!5 @サーバーサイド 東京(紀尾井町) Engineer x 3 + SRE x 2
⼤阪 PM x 1 + Engineer x 2 東京(豊洲) Engineer x 7 + SRE x 1 ホーチミン PM x 1 + Engineer x 2 + 通訳 x 1 合計: 20名のチーム
about me おかだ のぶお @bulbulpaul Yahoo!カレンダー Backend Engineer Python, Kotlin, Rust
!6 name: id: service: job: lang:
も く じ
[ 話すこと ] • Yahoo!カレンダー サーバーサイドの変遷と現状、抱える課題 • インフラの技術移⾏とこれから • なぜKotlinへ技術移⾏をするのか
[ 話さないこと ] • 細かなアーキテクチャ !8 もくじ
Yahoo!カレンダー サーバーサイドの変遷
!10 変遷 2000年 Ҿ༻: https://web.archive.org
!11 変遷 2005年 Ҿ༻: https://web.archive.org
!12 変遷 2012年 Ҿ༻: https://web.archive.org
!13 変遷 2014年
!14 変遷 2016年
!15 変遷 2017年 モバイルアプリとWebを統合
!16 変遷 2017年 スマートフォンWeb Yahoo! JAPANアプリ内 カレンダー
サーバーサイドの 抱える課題
!18 課題 • アプリケーションが細かく分割されすぎていて 修正コストが⾼い • PHPのアプリでFWを使っておらず個別の実装が多い • スケールが簡単にできない •
運⽤⾯でのコストが増え続ける このままでは安定して価値提供ができなくなる可能性も…
!19 価値とは • プロダクトとしての価値 ➡圧倒的なかんたんさ ➡圧倒的な⼼地よさ • サーバーサイドの価値 ➡ユーザー体験を⽀えるスループット, レイテンシ
➡ユーザーが増えても安定して可動する
!20 360ສUU ݄ؒΞΫςΟϒϢʔβʔ 10ԯ݅Ҏ্ ྦྷܭ༧ఆ݅ -2018 Q1- ࿙Εͳ͍ ফ͑ͳ͍ ࢭ·Βͳ͍
技術のあり⽅を再検討 Why What How
どうありたいのか
!23 Goal setting • 技術移⾏は⽬的じゃなく⼿段 • チームで話し合い、⾃分達の考えを⾔語化
ユーザーの為の時間を最⼤化
!25 Why • システムの為の作業 < ユーザの為の時間 • 場当たり的な選択ではなく少し⻑い⽬線で • 後向きな選択じゃなく、前向きな選択をしたい
• もっと多くの⼈に価値提供を続けていく為の戦略的選択
「適切な」技術選択をする
!27 適切な技術選択 • 組織が⼤きくなり、拠点も増え、システムも⼤きくなった • 過去の最適解が現在の最適解ではなくなっている • その中で⼀定のレベルを担保するためには ⾔語やFW, システム的な制約を設けたい
• インフラもより課題に合ったスケールしやすい環境へ
現⾏ Infrastructure !28 Language Middleware
技術移⾏ !29
⾔語 !30
インフラ !31
インフラの技術移⾏ !32
!33 課題 • アプリケーションが細かく分割されすぎていて 修正コストが⾼い • PHPのアプリでFWを使っておらず個別の実装が多い • スケールが簡単にできない •
運⽤⾯でのコストが増え続ける
インフラ !34
構成 !35 GSLB VIP VIP FE, Proxy FE, Proxy VIP
App App FE, Proxy FE, Proxy DB Secure NW ৽നՏDC भDC
サーバ増設 !36 GSLB VIP VIP FE, Proxy FE, Proxy VIP
App App FE, Proxy FE, Proxy DB Secure NW ৽നՏDS भDS VMを作成
サーバ増設 !37 GSLB VIP VIP FE, Proxy FE, Proxy VIP
App App FE, Proxy FE, Proxy DB Secure NW ৽നՏDS भDS Chefで 環境構築
サーバ増設 !38 GSLB VIP VIP FE, Proxy FE, Proxy VIP
App App FE, Proxy FE, Proxy DB Secure NW ৽നՏDS भDS L4認証設定
サーバ増設 !39 GSLB VIP VIP FE, Proxy FE, Proxy VIP
App App FE, Proxy FE, Proxy DB Secure NW ৽നՏDS भDS VIPへ追加
サーバ増設 !40 GSLB VIP VIP FE, Proxy FE, Proxy VIP
App App FE, Proxy FE, Proxy DB Secure NW ৽നՏDS भDS L4認証設定
SREてぃえうーっf」」」」」 !41 Stack Model
Stack Model SREてぃえうーっf」」」」」 !42
SREてぃえうーっf」」」」」 !43 Stack Model
!44
!45 インフラ移⾏ • 適切にマイクロサービスとして制御しやすいインフラへ • スケールアウトのしやすさ ➡オートスケール等の活⽤ • 耐障害性ももちろん重要 ➡オートヒーリング
Scale out !46 Node Node Node Node k8s Cluster Pod
Pod Pod Pod Pod Pod Pod Pod
Scale out !47 Node Node Node Node k8s Cluster Pod
Pod Pod Pod Pod Pod Pod Pod Pod Pod Pod Pod
Auto healing !48 Node Node Node Node k8s Cluster Pod
Pod Pod Pod Pod Pod Pod Pod
Auto healing !49 Node Node Node k8s Cluster Pod Pod
Pod Pod Pod Down… Node Pod Pod
Auto healing !50 Node Node Node k8s Cluster Pod Pod
Pod Pod Pod Down… Pod Node Pod Pod
Auto healing !51 Node Node k8s Cluster Pod Pod Pod
Pod Node Pod Pod Down… Node Pod Pod
Auto healing !52 Node Node k8s Cluster Pod Pod Pod
Pod Node Pod Pod Down… Node Pod Pod Pod Pod
Auto healing !53 Node Node k8s Cluster Pod Pod Pod
Pod Node Pod Pod Down… Node Pod Pod Pod Pod
kubernetes !54 Node Node k8s Cluster Pod Pod Pod Pod
Node Pod Pod Down… Node Pod Pod Pod Pod 認証は?
!55 AuthN, AuthZ • コンテナ化でIPベースの認証ができない • 適切なリソースの管理が必要 L7でAuthN, AuthZをする必要がある
!56
!57 Athenz • RBAC(ロールベースアクセス制御) System • IPに依存しない • Host毎にRoleの登録が不要でスケールしやすい •
他のインフラに依存しない
!58 認証形式 • Serviceという単位でアクセスを管理する IPの特定が不要、トークンを⽤いた⾝元特定 • ⾝元特定にも秘密鍵でデジタル署名されたトークンを ⽤いる事でPaaS, CaaSでの利⽤が可能 認証
Service 秘密鍵 公開鍵 トークン
!59 スケールのしやすさ • IPに依存しない為、⾼速なスケールアウトが可能 • 同じServiceとして扱う場合、アクセス権限が共有できる Service A IP :
aaa IP : bbb IP : ccc IP : ddd IP : eee 追加 追加 認証 IP : ddd Service B
Appの追加 !60 VM VM VM VM CF Cluster App App
App App App
Appの追加 !61 VM VM VM VM CF Cluster App App
App App App App App App App App App App
Appの追加 !62 VM VM VM VM CF Cluster App App
App App App App App App App App App App
⾔語 !63
PHP → Kotlin? なんで ?
!65 Why • システム全体で⾒たときに コードの可読性や挙動の把握が現状しづらい点がある • 実⾏時のエラーではなくコンパイル時に気づきたい • 可能な限り静的な解析や型等を導⼊する事で最低限の 品質担保をしたい
!66 Why Kotlin? • Null Safe • sealed class •
型 / 型推論 • Smart Cast • data classが便利 • IDEのサポートが強⼒ • Javaのエコシステムを使える
• Null Safe • sealed class • 型 / 型推論
• Smart Cast • data classが便利 • IDEのサポートが強⼒ • Javaのエコシステムを使える !67 Why Kotlin? 制約と規律
• Null Safe • sealed class • 型 / 型推論
• Smart Cast • data classが便利 • IDEのサポートが強⼒ • Javaのエコシステムを使える !68 Why Kotlin? ⾼い利便性
!69 Why Kotlin? 巨⼈の肩に乗れる • Null Safe • sealed class
• 型 / 型推論 • Smart Cast • data classが便利 • IDEのサポートが強⼒ • Javaのエコシステムを使える
型, 型推論 !70
!71 型がある幸せ • Kotlinは型が厳格でコードの挙動も把握しやすい • sealed class 等の制約もかけやすい • IDEの強⼒なサポートもあり振る舞いに問題がある場合
エラーになるので意図しないミスも防げる • 型推論があるので冗⻑にならず簡略に書け便利
!72 Sealed class // sample.kt sealed class Protocol{ abstract val
seq abstract val id } data class SampleProtocol(val seq, val id) : Protocol 同⼀ファイル内のみ継承可能 ※異なるファイルから継承しようとするとコンパイルエラー
!73 型推論 val name = “デブサミ” // String, val name: Stringとなる
val count = 2018 // Int, val count: Intとなる // Spring JDBCのコード例 val count: Long = jdbcTemplate.queryForObject( “SELECT count(*) FROM user”) 左辺の型推論
NullSafe !74
!75 Null Safe val task: String? = null // nullable
val name: String = “okada” // non null name.contains(“ok”) // 実⾏可能 task.contains(“ok”) // コンパイルエラー
制約で最低限の規律ができる
KotlinのFramework? !77 どうなん?
!78 Framework • 基本的にJavaのエコシステムを活⽤できる • Spring Framework v5からKotlin Support •
SpringBootも使えるので導⼊コストも低い • Kotlinで実装されたFWもある(Ktor, Spring Fu, etc ) • 現時点ではSpringBootが周辺ライブラリも揃っている状況
活⽤してるJavaの エコシステム !79 何使ってんの?
• Athenz(認証 / 認可) • Pulsar Client (MQ) • Hystrix
(サーキットブレーカー) Use library • SpringBoot (Framework) • MVC • Batch • Moshi (Json parser) Javaライブラリ Kotlin対応ライブラリ !80
JavaライブラリのKotlin対応 なにが違うん?
• Kotlinらしく書ける • 動かない等は無い • 場合によっては⾔語特有の部分で 意図しない挙動になる場合もある !82 Kotlin support
public class Example { public <T> T create(Class<T> clazz) {
try { return clazz.newInstance(); } catch (Exception e) { e.printStackTrace(); } } !83 example 1
// Kotlin val example = Example() example.create(Foo::class.java) !84 example 1
// Java Example example = new Example() example.create(Foo.class)
val example = Example() example.create(Foo::class.java) !85 example 1 Example example
= new Example() example.create(Foo.class) kotlin.reflection.KClass java.lang.Class
import kotlin.reflect.KClass fun <T: Any> Example.create(kclass: KClass<T>) = create(kclass.java) val
example = Example() example.create(Foo::class) !86 example 1 Kotlinらしい書き⽅!!
@Controller class ExampleController(val foo: Foo, val bar: Bar?) { @GetMapping(“/article”)
fun article(@RequestParam id: String, @RequestParam tag: String?) } !87 example 2 オプション 必須 @RequestParam(required = false) String name
PHPからKotlin? !88 どうなん?
!89 ⾔語の移⾏ • 学習コストはあるものの、⾔語移⾏で躓く等は発⽣していない • ⾔語⾯での仕様や制約を上⼿く使って 全体での品質向上等へつなげる • 「作りたいもの」を作りやすい技術を選ぶ事で ⽣産性を⾼める
• チーム内の定性的な反応としては 「開発が楽しくなった!!」との声も!
Next Challenge
!91 Challenge • システム • 部分的にPHP -> Kotlinへ移⾏中 • 後々Java
-> Kotlinも移⾏したい • インフラ • Istio, Envoy を使ってカナリアリリース可能な環境の構築
技術移⾏ !92
ユーザーの為の時間を最⼤化
チームづくり どうしとん?
!95 チーミング • 距離がある分コミュニケーションコストは⾼い ➡だから価値あるコミュニケーションにはコストをかける • お互いを知るためにメンバー間で1on1 • チーム全体でお互いの期待値を全体で合わせる ➡ドラッカー⾵エクササイズ
!96 期待値合わせ • お互いの期待値を合わせるために 以下の項⽬を ➡ 得意なコト ➡ 貢献しようとしてるコト ➡
メンバーからの期待されているコト 必ずしも期待されてることが正じゃないように注意
!97 他にも • 4拠点で毎⽇の朝会で顔を合わせる場を作る • ペアプログラミング • 全体の開発⼒や知識レベルの底上げの為のハンズオン
ま と め
!99 まとめ • 技術移⾏はあくまで⼿段 • より「ユーザーのための時間を最⼤化」させるという⽬的の為に 技術移⾏をし、適切な技術選択を進めている • KotlinやFWの仕様や特性を⽣かして、品質や⽣産性を⾼める •
インフラもよりモダンな環境へ移⾏することで ユーザーが増えても変わらない価値提供をする 取り組みをしています • 技術だけじゃなくチームづくりも並⾏して⾏うことで 前向きな選択ができる強いエンジニアリング組織にしていく事も重要
さ い ご に
!101 Mix Leap https://about.yahoo.co.jp/hr/
!102 Mix Leap ൃ৴ ަྲྀ ڞ 「発信」「交流」「共創」の3つを軸に 「関⻄圏のクリエイターを⽀援」するためのイベント
お わ り