知見のない技術スタックをプロダクション導入するエンジニアの導入戦略 / A strategy to choice no knowledge technology

PHPカンファレンス2019にて発表する資料です。知見のない技術スタックを扱おうと検討した際に重くのしかかる「運用実績のない」という事実にどう向き合うかという説明をしています。

Transcript

1. © - BASE, Inc. X 知⾒のない技術スタックを プロダクション導⼊する エンジニアの導⼊戦略 . . - Japan PHP Conference @hgsgtk
2. © - BASE, Inc. 本⽇お話すること • 技術選定の意思決定の不安の⼀要因を和 らげる導⼊戦略 • 開発‧運⽤の知⾒を得て改善する、 フィードバックループをいかに回すか • テストとコード検査、監視を武器に不安 と⽴ち向かう
3. © - BASE, Inc. ※ 本⽇話す背景となる題材 • BASEにおける新規事業にて、既存サー ビスで運⽤経験のなかったプログラミン グ⾔語（Go）を⽤いたシステム開発を ⾏いました • この経験を⼀般化したため、サーバーサ イドのレイヤに焦点を当てて話します
4. © - BASE, Inc. About me BASE BANK, Inc. Dev Division Tech Lead 『みんなのPHP 現場で役⽴つ最新 ノウハウ!』共著者 （PHPにおけるユニットテスト） https://www.amazon.co.jp/ gp/product/ @hgsgtk Kazuki Higashiguchi
5. © - BASE, Inc. Agenda 実際に不安の要因に対してどう取り組ん でいくか 知⾒のない技術スタックを扱う不安にど う取り組むか テスト‧コード検査‧監視を武器に⽴ち向 かう
6. © - BASE, Inc. Agenda 実際に不安の要因に対してどう取り組ん でいくか 知⾒のない技術スタックを扱う不安にど う取り組むか テスト‧コード検査‧監視を武器に⽴ち向 かう
7. © - BASE, Inc. 学習コスト ⽋陥発⽣の抑制 プロダクション採⽤実績数 パフォーマンス エンジニアの採⽤ メンテナンス性 エンジニアのモチベーション etc チームでの運⽤実績 サービス性質との相性 技術選定をする際の様々な観点
8. © - BASE, Inc. 技術選定の判断軸 • 要件によってどの観点が重視されるかは 異なる • 考えうる判断軸で複数の選択肢を⽐較し 決断する必要がある • 結果的に、運⽤実績がない技術のほうが マッチしそうなケースもある
9. © - BASE, Inc. 運⽤実績の無さは意思決定に重くのしかかる 技術選定観点 ⾔語A ⾔語B ⾔語C パフォーマンス ◦ ◦ ◎ サービス性質との相性 △ ◦ ◎ エンジニアの採⽤ ◦ △ ◦ チームでの運⽤実績 ◎ △ ×
10. 知⾒のない技術スタックを プロダクション導⼊する https://unsplash.com/photos/Oh oxXi RQQ
11. © - BASE, Inc. 知⾒のない技術スタック • 例えば、運⽤実績のない⾔語‧フレーム ワーク • あるいはクラウド技術やアーキテクチャ • これらを導⼊する意思決定において、 「未知への不安」が重くのしかかる
12. © - BASE, Inc. 知⾒のない技術スタックを導⼊する不安 未知への不安、知⾒がないがゆえに尻込 みしてしまう 運⽤知⾒がないけど⼤ 丈夫か？ それらしいコードが成 果物としてできるか？ 不具合なくリリースで きるか？ etc
13. © - BASE, Inc. 結果的に、フラットな意思決定から遠ざかってしまう 技術選定観点 ⾔語A ⾔語B ⾔語C パフォーマンス ◦ ◦ ◎ サービス性質との相性 △ ◦ ◎ エンジニアの採⽤ ◦ △ ◦ チームでの運⽤実績 ◎ △ × >
14. © - BASE, Inc. この不安をさらに深堀りする 読みやすく変更しやす いコードにできる？ 運⽤知⾒がないけど⼤ 丈夫か？ それらしいコードが成 果物としてできるか？ 不具合なくリリースで きるか？ ⽋陥の少ないシステ ムにできる？ etc 安定稼働するシステ ムが運⽤できるか？
15. © - BASE, Inc. この不安をさらに深堀りする 読みやすく変更しやすい システムにできる？ 運⽤知⾒がないけど⼤ 丈夫か？ それらしいコードが成 果物としてできるか？ 不具合なくリリースで きるか？ ⽋陥の少ないシステムにで きる？ etc 安定して稼働するシステム が運⽤できるか？ 将来の成果物の品質に対する不安
16. © - BASE, Inc. 品質の問題を分類する • 品質には外部品質と内部品質がある • 外部品質は、ユーザーから⾒える、外か ら⾒える品質‧価値 • 内部品質は、ユーザーから⾒えない、し かし⻑期のメンテナンス性に影響をもた らす
17. © - BASE, Inc. “External quality is how well the system meets the needs of its customers and users (is it functional, reliable, available, responsive, etc.), and internal quality is how well it meets the needs of its developers and administrators (is it easy to understand, easy to change, etc.).” “Freeman, Steve. Growing Object-Oriented Software, Guided by Tests” / Chapter . What Is the Point of Test-Driven Development? External and Internal Quality
18. © - BASE, Inc. 品質に対する不安を整理すると 読みやすく変更しやすい システムにできる？ 運⽤知⾒がないけど⼤ 丈夫か？ それらしいコードが成 果物としてできるか？ 不具合なくリリースで きるか？ ⽋陥の少ないシステムにで きる？ etc 安定して稼働するシステム が運⽤できるか？ 外部品質 内部品質
19. © - BASE, Inc. 内部品質への投資の損益分岐点 Martin Fowler “Is High Quality Software Worth the Cost?” https://martinfowler.com/articles/is-quality-worth-cost.html
20. © - BASE, Inc. 品質の不安にどう⽴ち向かう • いくらプライベートで学んだところで、 業務で開発しないとわからない壁はある • いわゆる「開発‧運⽤の知⾒」 • これらはやりながら知⾒を得てプロダク トに反映していくしか無い
21. いかに多く学び すぐに反映するか https://unsplash.com/photos/ fNmWej tAA
22. © - BASE, Inc. - Summary - 知⾒のない技術スタックを扱う不安にどう取り組むか • 不安の要因を品質問題に帰着、外部品質‧内部品 質と分けて捉える • “よりよい品質”を⽬指すための開発‧運⽤知⾒ を、動きながら学びシステムに反映する • この道筋が⾒えれば「運⽤実績の無さ」を重く捉 えすぎず、意思決定できるのではないか
23. © - BASE, Inc. Agenda 実際に不安の要因に対してどう取り組ん でいくか 知⾒のない技術スタックを扱う不安にど う取り組むか テスト‧監視‧コード検査を武器に⽴ち向 かう
24. © - BASE, Inc. このトークの舞台
25. © - BASE, Inc. Mission Payment to the People, Power to the People. ひとりひとりに眠る、想いが、感性が、才能が。 世界中の、必要な⼈に届くように。 そこから⽣まれる、作品に、アイデアに、活動に。 正当な対価を、受け取れるように。 ペイメントを、世界中の⼈へ解放する。 世界のすべての⼈に、 ⾃分の⼒を⾃由に価値へと変えて ⽣きていけるチャンスを。 あたらしい決済で、あなたらしい経済を。
26. © - BASE, Inc. Eコマースプラットフォーム「BASE」 ネットショップ作成サービス 「BASE（ベイス）」 ショッピングアプリ 「BASE（ベイス）」
27. © - BASE, Inc. ネットショップ作成サービス「BASE」 専⾨知識がなくても 無料で即座にネットショップを開設でき ます。 また個⼈でも、かんたん‧スピーディに 決済機能を導⼊できる仕組みを提供して います。 「誰でもかんたんに使える」サービスで ⾃分のネットショップを開設
28. © - BASE, Inc. 開設ショップ数の推移
29. © - BASE, Inc. オンライン決済サービス「PAY.JP」 ⽀払いのすべてをシンプルに WebαʔϏε΍ωοτγϣοϓʢ஫ʣʹΫ ϨδοτΧʔυܾࡁΛ؆୯ʹಋೖͰ͖Δ ։ൃऀ޲͚ͷΦϯϥΠϯܾࡁαʔϏεͰ ͢ɻ Θ͔Γ΍͍҆͘͢ྉۚମܥͱɺγϯϓϧͳ API΍๛෋ͳϥΠϒϥϦΛ࢖ͬͯɺεϜʔ ζʹܾࡁΛಋೖ͍͚ͨͩ·͢ɻ （注）BASEにより作成されたネットショップを除く
30. © - BASE, Inc. 資⾦調達サービス「YELL BANK」 「BASE」を利⽤するショップオー ナーが即時に資⾦調達できる⾦融サー ビス 将来債権が発⽣しないリスクや、将来 未回収リスクを「YELL BANK」が負 担するため、ショップオーナーはこれ らのリスク無く資⾦調達可能 資⾦調達をリスクなく、⼀瞬で。
31. © - BASE, Inc. 資⾦調達サービス「YELL BANK」 「BASE」を利⽤するショップオー ナーが即時に資⾦調達できる⾦融サー ビス 将来債権が発⽣しないリスクや、将来 未回収リスクを「YELL BANK」が負 担するため、ショップオーナーはこれ らのリスク無く資⾦調達可能 資⾦調達をリスクなく、⼀瞬で。 今回の題材はこちらのサービス開発
32. © - BASE, Inc. YELL BANK プロジェクト 概観 • 2018年12⽉ 初期リリース、約5ヶ⽉の開発 期間、2019年12⽉現在もサービス提供中 Director Server side engineer Designer SRE （初期リリース時の⼤まかな開発体制）
33. © - BASE, Inc. YELL BANKを取り巻く技術スタック概観 etc
34. ⾛りながら学び 改善していく https://unsplash.com/photos/V UrdknDCA
35. いかに現場の知⾒を 得るか https://unsplash.com/photos/QchJkuTGxJQ
36. © - BASE, Inc. いかに現場の知⾒を得るか • 無戦略で “なんとなく” やっていても、 得られるものは少ない • 多くの知⾒を得て、サービスに反映させ るための導⼊戦略を考える
37. © - BASE, Inc. 学びのサイクル ⻄尾 泰和. エンジニアの知的⽣産術 効率的に学び、整理し、アウトプットする 第1章 新しいことを学ぶには 応⽤ 具体 抽象 情報収集 体験 実践 検証 抽象化‧モデル化‧パターンの発⾒
38. © - BASE, Inc. 学びのサイクル ⻄尾 泰和. エンジニアの知的⽣産術 効率的に学び、整理し、アウトプットする 第1章 新しいことを学ぶには 応⽤ 具体 抽象 情報収集 体験 実践 検証 抽象化‧モデル化‧パターンの発⾒ 多く学び すぐ反映
39. © - BASE, Inc. “きちんと観察すれば、いろいろ⾒ えるものだ.” https://en.wikipedia.org/wiki/Yogi_Berra - Yogi Berra -
40. © - BASE, Inc. 観察して経験から得られる気づきを増やす 外部品質 内部品質
41. © - BASE, Inc. 観察して経験から得られる気づきを増やす 外部品質 内部品質 テスト 監視 コード検査
42. © - BASE, Inc. - Summary - 実際に不安の要因に対してどう取り組んでいくか • 学びのサイクルを、⾛りながら観察し ていくことで、早めていく • 情報収集の武器として、テストとコー ド検査、監視からフィードバックを得 て、学びを反映していく
43. © - BASE, Inc. Agenda 実際に不安の要因に対してどう取り組ん でいくか 知⾒のない技術スタックを扱う不安にど う取り組むか テスト‧コード検査‧監視を武器に⽴ち向 かう
44. © - BASE, Inc. 観察して経験から得られる気づきを増やす 外部品質 内部品質 テスト 監視 コード検査
45. © - BASE, Inc. テストを⾍眼鏡として使う • コード設計のリトマス試験紙 • 勇敢なリファクタリングの盾
46. © - BASE, Inc. • コード設計のリトマス試験紙 • 勇敢なリファクタリングの盾 テストを⾍眼鏡として使う
47. © - BASE, Inc. “良い設計はテスト可能であり、テスト可 能でない設計は悪い設計である” マイケル‧C‧フェザーズ. レガシーコード改善ガイド 第10章 このメソッドをテストハーネスで動かすことができません
48. © - BASE, Inc. テストコードを書くことで気づく • 悪いコード設計をした場合、内部品質に 影響を与える • テストは⽋陥を防ぐ⽤途に⽬が向きがち だが、それだけではない • テストコードを設計道具として使う、設 計に対するフィードバックを得る
49. © - BASE, Inc. テストを書くことで気づけるフィードバック例 APIなど外部環境などに極度に依存している 過責務なモジュールとなっているコード設計 etc 依存関係を差し替え不可なコード設計 Untestableなビジネスロジック
50. © - BASE, Inc. テストを書くことで内部品質に気づく • テストコードを書くことで、コード設計の良し悪 しを体験する • その体験から、当該技術において内部品質のより ⾼いコード設計を⽬指す気づきを得る • 今回の例では、「Goにおけるテスタブルなコード 設計」を体験‧抽象化‧実践していた
51. © - BASE, Inc. @see TDDでテストを設計道具として使う https://speakerdeck.com/hgsgtk/test-driven-development-to-avoid-test-painful
52. © - BASE, Inc. • コード設計のリトマス試験紙 • 勇敢なリファクタリングの盾 テストを⾍眼鏡として使う
53. © - BASE, Inc. “リファクタリングとは、ソフトウェアの外部の振る 舞いを保ったままで、 内部の構造を改善していく作 業を指します。 ⾮常に統制された⽅法でコードを洗 練していくため、 バグの⼊り込む余地はほとんどあ りません。 リファクタリングを⾏えば、以前に書い たコードの設計が向上することになります。” ＭａｒｔｉｎＦｏｗｌｅｒ. 新装版 リファクタリング 既存のコードを安全に改善する / はじめに
54. © - BASE, Inc. “リファクタリングを開始するとき、最初にすること は常に同じです。対象となるコードについてきちん としたテスト群を作りあげることです。” ＭａｒｔｉｎＦｏｗｌｅｒ. 新装版 リファクタリング 既存のコードを安全に改善する / リファクタリングの第⼀歩
55. © - BASE, Inc. 勇敢なリファクタリングな盾 • 運⽤実績無い場合、メンテナンス性を本当に意 識したコードを書く機会はほぼなかったはず • ⾃分の書いたコードは、必ずリファクタリング される • テストコードを盾に、⾃分たちが経験し抽象化 したアイデアを、即座に実践して改善していく
56. © - BASE, Inc. 損益分岐点の到達はリリース前に訪れる Martin Fowler “Is High Quality Software Worth the Cost?” https://martinfowler.com/articles/is-quality-worth-cost.html
57. © - BASE, Inc. @see Goを⽤いたプロジェクトでの実例 https://speakerdeck.com/hgsgtk/building-api-server-side-architecture-for-beginners
58. © - BASE, Inc. 観察して経験から得られる気づきを増やす 外部品質 内部品質 テスト 監視 コード検査
59. © - BASE, Inc. その技術の標準的なやり⽅は？ • ⾔語をプロダクションでやり始める不安 は、「XXXらしいコードになっているだ ろうか」という点 • そうなっていない場合、後続のエンジニ アが⼤いに⼾惑ってしまう可読性の悪い コードになりうる
60. © - BASE, Inc. 標準を指導する教師役 • 各⾔語、その⾔語圏での標準的な書き⽅に矯正す るコードフォーマッターやコード検査ツールがあ る • それに従うことで、その⾔語らしい書き⽅を⾝に つけ、守る • また、静的解析などを活⽤し、コードを動かさな くても分かる⽋陥を防ぐ
61. © - BASE, Inc. @see Pythonを⽤いたプロジェクトでの実例 https://speakerdeck.com/hgsgtk/python-api-ci-test
62. © - BASE, Inc. 観察して経験から得られる気づきを増やす 外部品質 内部品質 テスト 監視 コード検査
63. © - BASE, Inc. 安定運⽤への懸念事項 • 動かし続けないとわからないことがある • リリースと同時、あるいは直前から動か し始めるのでは、気がつけない落とし⽳ があるかもしれない
64. © - BASE, Inc. 動き続けることをシミュレーションするために • プロジェクト早期からデプロイする • 稼働状態を監視し続けておく • 外形監視 • メトリクス計測
65. © - BASE, Inc. 早期にデプロイすることで気がついた例 • リリース前のアプリケーションに対して外形監視 を⾏っていた • 突然、アプリケーションからデータベースへの疎 通確認が途切れる事象が⾒受けられた • Goを使った⼀般的なデータベースアクセスの⼀つ として、sql/databaseパッケージを⽤いて connection poolingを⾏う⽅法がある • 結論として、アプリケーションに与えるべき設定 が不⾜していたことがわかった
66. © - BASE, Inc. @see 詳細はこちらをご覧ください https://qiita.com/hgsgtk/items/ c f b da f
67. © - BASE, Inc. “計測する必要がありそうな箇所はたくさんあります が、⼿をつけるのに最適な場所があります。それは ユーザーです” - ⼊⾨監視 / 2章 監視のデザインパターン - https://www.oreilly.co.jp/books/ /
68. © - BASE, Inc. どこから着⼿するか • やろうと思えばいくらでも出来るが、現 実的には時間の制約がある • できるだけユーザーに近いところから監 視を始める • 最低限アプリケーションが提供可能な状 態かどうか（Readiness）
69. © - BASE, Inc. 早期にデプロイした副次効果 • 早期にデプロイしたことによって、必然的にアプ リケーションは運⽤を意識する • 監視⽅法、ログや設定情報の扱いの必要性を体験 する • ⼀般化されたパターンと⾃⾝のアプリケーション を照らし合せて実践するようになる
70. © - BASE, Inc. @see コンテナを使う場合のアプリケーション設計 https://speakerdeck.com/hgsgtk/design-considerations-for-container-based-go-application
71. © - BASE, Inc. - Summary - テスト‧コード検査‧監視を武器に⽴ち向かう • テスト‧コード検査‧監視を⾏うこと によって得られる体験‧フィードバッ クを活⽤する • 得られたフィードバックをサービスに 反映することで、⾛りながら学び改善 する
72. © - BASE, Inc. まとめ
73. © - BASE, Inc. まとめ • 知⾒のない、つまり運⽤実績のないことが、技 術選定の意思決定において、重しになりうる • 運⽤実績のないものを、いかにスピーディーに 学び品質を上げるか、⼀つの体験から得たアイ デアを説明しました
74. © - BASE, Inc. フラットな意思決定に近づけるのではないか 技術選定観点 ⾔語A ⾔語B ⾔語C パフォーマンス ◦ ◦ ◎ サービス性質との相性 △ ◦ ◎ エンジニアの採⽤ ◦ △ ◦ チームでの運⽤実績 ◎ △ × ＜
75. © - BASE, Inc. “「たいていのチャンスのドアにはノブが無 い」と‧‧‧ ⾃分からは開けられない だれかが開けてくれたときに迷わず⾶び込んで いけるかどうか そこで⼒を出せるかどうか” - ちはやふる 23巻 第百⼆⼗⼀⾸ - https://www.amazon.co.jp/dp/B J TVQQ
76. © - BASE, Inc. Be Hopeful 楽観的でいること。 期待した未来は実現すると信じて、 勇気ある選択をしよう。 https://binc.jp/jobs - BASE ⾏動指針のひとつより -
77. © - BASE, Inc. Beyond your XXX
78. https://devblog.thebase.in/entry/ / / / アドベントカレンダーやります！
79. ブースでお待ちしています
80. © - BASE, Inc. X <?php exit();