🍄

ベストプラクティス・ドリフトについて

2022/07/19に公開

ベストプラクティス

idea

はじめに

この記事は「ベストプラクティス・ドリフト~技術選定におけるベストプラクティスの老朽化にどう抗うか~」というタイトルで話した内容の台本だ。

経緯としては会社でテックカンファレンスをやることになり、なに話してもいいよとリクエストをいただいてたので、自分が好きな技術選定をテーマに話をさせていただいた。

ベストプラクティスという理想の解を追い求めてるエンジニアは自分を含めて決して少なくないと思う。その場その場はいい感じでも長年のベストプラクティスの変化を見届けると、おっさん目線ではどうしても平家物語の冒頭のような悲観主義が先立ってしまう。

「ずっと技術選定を運用していたら、ベストプラクティスって言われていたどんなものも、いつかオワコンって言われてしまう時代が来るよね」

社内の自分だ。そうした陰口をたたかれぬため、いえ、常にベストプラクティスを最新化し続ける努力を欠かさないようにするために、社内で実際に技術選定を行っている人はどんなことをしているのだろう。そんなノリで会社の偉い人にインタビューを行って、聞いた内容を自分の考えと合わせてまとめたのが「ベストプラクティス・ドリフト」ってセッションだった。

スライド

本編

導入

私は技術史が好きで、特にどうしてこういう技術が生まれたのか？あるいは必要とされたのか？時代背景やビジネスとマッピングさせることが好きです。

特にここ十年はクラウドサービスの登場により、毎週のように新しいサービス、機能が登場し、数年前がすぐに歴史となってしまう現状を非常に楽しんでおります。

ですが、そうした現状で困った問題が生じるようになりました。

ベストプラクティスの陳腐化です。

システムを構築するとき、いろんな選択肢がある中で、一つを選ばないといけません。その指針となるのが、かつてこうすればうまくいったというベストプラクティス集ですが、このような経験はありませんか。

"ベストプラクティス" 、古臭くないか？

あの時、あの時代は問題なかったのに、コストの変化や技術革新によりベストだった解がいつのまにか、まぁ及第点？、うーん微妙、最悪、といった形になっていく...

これによく似た概念、知られた言葉として技術負債、っていうのがあります。長年運用していたシステムがいつのまにか誰も全容を知らない化け物に変わっていき、負債の名の通り、重くのしかかってきます。

でも、考えてみてください。その場、その場の判断は当時の時代背景を反映したものであり、その時代に持ち合わせていた情報では最善だったわけです。それに対して今の情報基準、価値観で判断して、腐ってるね、時代遅れだねっていわれるのはわりと心に来る話ではないでしょうか。

そこで、自分はあえて
ベストプラクティスの陳腐化といわず、
ベストプラクティス・ドリフト
といっています。

ドリフト=船の漂流から転じて、システム界隈だと設計と実装のズレ、ギャップとしてよく使われている言葉です。

インフラストラクチャー・ドリフト
例えばインフラストラクチャーの文脈においては、Terraformなどのソースコードと、実際のプロダクトサービスとのズレ、ギャップに関する定義を指します。IaCで管理されていないリソースを検知するdriftctlなんていうツールがあったりします。

データ・ドリフト
機械学習の文脈においては、データドリフトというのがあり、予測モデルが長期間の運用により劣化してくる状態を指し、機械学習パッケージはこのデータドリフト検知を売りにしているところもあります。

これらを踏まえた上でベストプラクティス・ドリフトをこのように定義しました。

ベストプラクティス・ドリフト:
コストの変化や技術革新により覆されたにもかかわらず、過去に常識、鉄板とされていたことをそのまま踏襲してしまうこと

本日はこのベストプラクティス・ドリフトに対して
・ベストプラクティス・ドリフトはそもそもなぜ生じるのか？
・ベストプラクティス・ドリフトが起きるとどういった不都合が生じるのか？
・ベストプラクティス・ドリフトに抗うためには？
といった話をしたいと思います。

ベストプラクティス・ドリフトはそもそもなぜ生じるのか？

ベストプラクティス・ドリフトはそもそもなぜ生じるのか？
会社が時代遅れだから、昔に固執するからってするのは単純ですが、
ソフトウェアの周りを改めて見渡してみると、そもそも時代の進化が早すぎると改めて思いませんか。

例えば、AWSが公開しているベストプラクティスをセルフレビューすることができるツール、
AWS Well-Architected Toolのドキュメントヒストリーを見てみましょう。

恐ろしい勢いで変わってますよね。

実際、今の時代、ベストプラクティス・ドリフトは非常に起こりやすい状況にあります。
その理由の一端にソフトウェアの開発を取り巻く状況の変化、すなわちOSSへの依存の高さがあります。

理屈はこうです。
→ソフトウェア、サービスがOSSに依存するようになる
→依存先のOSSが頻繁に更新されて、新機能の拡充、改修が行われる
→OSSを利用するサービスが理由を問わず頻繁に更新される
→結果として、更新や変更が一般的になり、ソフトウェア業界そのものの進化が進む

この中で大きく影響を与えているのがOSSの更新頻度です。

例えばソフトウェアを支える根幹であるプログラミング言語を例に挙げてみましょう。

注目すべきはバージョン間の期間です。
Rustが6週間
Go言語が数か月
Javaですらも半年単位です。
Rust, Go言語, Javaですらもリリース時期が短くなっていますよね

なぜ、OSSのバージョンが頻繫に更新されるのでしょうか？そして短いのでしょうか。
それを可能にした技術として、CI/CD環境やテストコードのフレームワークの充実などありますが、
長くても別にいいわけです。そこで注目したいのがOSSの構造的な課題である...人気とメンテナンスの関係性です。

GitHub上のJavaライブラリをベースに、バージョン更新がAPIの互換性、そしてライブラリを利用するユーザーにどれくらい影響を与えているかを調べた2017年の調査論文があります。

Historical and Impact Analysis of API Breaking Changes: A Large-Scale Study

この論文によると、実世界の317のJavaライブラリ、9000のリリース、26万のクライアントアプリケーションを対象とした大規模な分析により、
(i) API変更の14.78%は旧バージョンとの互換性を破壊していること
(ii) API変更の破壊頻度は時間とともに増加すること
(iv) API変更の破壊頻度が高いシステムほど大規模、人気、活発であること
などがわかったそうです。

要はバージョン更新の頻度が大きく修正を要求されるソフトウェアほど、より利用者に人気であり、開発に協力してくれる人も集めていたというものです。

開発者と利用者、この二者が揃わないとOSSを健全な状態で維持することは難しいと思います。
それは過去に起きたセキュリティインシデントの一例を見てもわかるのではないでしょうか。

変化し続けるマインドを持つOSSがプロジェクトもコミュニティも成長することができると言いきっていいのかもしれません。
OSSにおける進化の速さが巡ってソフトウェア業界に影響を及ぼし、ベストプラクティス・ドリフトが起きやすくなっているんですね。

ベストプラクティス・ドリフトが起きるとどういった不都合が生じるのか？

ゲームの話をさせてください。

大昔はバイナリを詰めに詰めて効率良いリソースの利用を求められてました

しかし、昨今ではもちろんコンシューマー機には制限があるので効率の良さは求められるけど、そういった処理負荷を削減する技術よりも
DLCの追加販売を見据えた、継続的な発展、拡張を踏まえた保守性だったり、昔よりはるかに大規模化したプロジェクトならではの
ゲームエンジンや開発標準に従ったわかり易さがより重視されてますよね。

こういったことを前提とせずに開発に関して昔のベストプラクティスに沿ってしまうとどうなるか？

時代遅れのビジネスモデルの誕生です。

技術選定、ベストプラクティスは、私のような濃ゆい人にとどまる話ではない。
ベストプラクティスとビジネスモデルには切り離せない関係があります。
フューチャーで行っている事例を説明します。

技術選定とビジネスモデルの関り~ウィナーズサークルを例に~

弊社では技術選定に対して、ウィナーズサークルというものを作成し、どのような技術が
今のベストプラクティスなのか、中長期的に利用するOSS含むプロダクトを技術領域別に選定し、定期的に検証を行っています。いわば格付けですね。

弊社ではこのウィナーズサークルの見直し、変更を経営戦略の一環として行っています。

したがってウィナーズサークルの入れ替えは様々な観点でチェックを行っています。

大規模データにおけるパフォーマンス
Persistent層(DB, ストレージ)における扱いやすさ
運用の容易性(障害発生時のリカバリプラン等への習熟度)
開発・保守する人員のアサインのしやすさ
既に終わったプロジェクトのポストモーテムの評価

など...

しかし、ベストプラクティスがベストプラクティス足りえたことを知るのはいつもあとの祭りであり、ベストプラクティスの見直し、変更には緊張が伴います。

この緊張がピークを迎えたのが、商用DBからPostgreSQLへ切り替えたときでした。

2010年代の中頃、ウィナーズサークルのうち、弊社でDBの優先度を変えようという機運が持ち上がりました。

基幹系DBについてとある商用データベースではなくPostgreSQLを使おう。

品質、性能など当然事前に検証できる課題はクリアしていたが、不安は大きいものでした。

人材リソース(プラチナホルダーの称号)、品質、性能、メンテナンス諸々...失うものはいろいろあったわけです。会社の偉い人たちを巻き込む話になりました。

未来は正直わからないがそれでもやろう。最後に押し通したのは理屈抜きのパッションだったと聞きます。そこからはプロジェクトXの始まりです。あのBGMが毎日脳裏をめぐる日々だったと聞きます。ですが結果として今の目線から振り返れば分散SQL、NewSQLへの対応等、現状のニーズに非常にマッチした形になりました。

ベストプラクティスは常に新しいビジネスモデルに対応した技術を選択するためにある。
...だが、その決め手の最後は技術への愛だ。

ウィナーズサークルの運用を通じて学んだ自分たちのモットーです。

ベストプラクティス・ドリフトに抗うためには？

最後に、ベストプラクティス・ドリフトに抗うためには？という話をします。

正直これは難しい問題です。技術負債とよく似た文脈ではありますが、技術負債は既に存在している技術にたいして起こるのに対して、ベストプラクティス・ドリフトはこれから技術選定しようとしている技術に対して起こるからです。

その中でこれは大事にしていると思う軸を大きく二つまとめました。

ベストプラクティスに入れるために:
- 現状抱えている問題を解決してくれそうな技術への情報感度を高くする
ベストプラクティスから外すために:
- ベストプラクティスになぜそれを入れたのか、技術的な時代背景を明確にする

ベストプラクティスに入れるために

ベストプラクティスに新技術を仲間入りさせるのはわりと簡単です。
流行ってて開発者も利用者も大勢いてIDEなどの開発環境が整っていれば採択したくなります。
...ですが、昨今では逆に対抗する新技術が多すぎて一つを選ぶのに悩むという贅沢な問題が生じてきました。

流行を追いかけることはベストプラクティス・ドリフトに抗うために、いえ、本音を言えば技術者の性として皆様やられていると思いますが
選択肢を絞るためにもう一軸置きたいのが現状抱えている問題を解決してくれそうな技術への情報感度です。

今問題である、こういうことができないけど実現したらいいなと思うことは、たいてい他の技術者も思っている課題です。自分の開発力があれば自力で開発するのですが、自分はそこまでないので、社内のコアテクメンバー、スーパーエンジニアに他力本願しています。

その足りないなと思うことに対してどういった機能要件、あるいは非機能要件を満たしていないから不満に思っているのか、軸を書き出すことでクラウドサービスのリリースノートが発表されたときなどに、この機能は課題を解決してくれそうだからベストプラクティスに組み込めるぞとなるわけです。

例えば負荷試験ツールでk6というツールがあります。今はGrafanaLabsにjoinしましたが、その前にhackernews等で話題になったテックブログがあります。

それは他の負荷試験ツールと比較して、k6がどのようなメリットがあり、課題を解決しているのか、k6の中の人が書いたセルフレビューでした。

負荷試験ツールはE2Eテストの重要性が周知されている昨今、当時既に非常に多くのライバルがいました。

Apache Bench
Artillery.io
Drill
FloodElement
Fiddler
Fortio
Gatling
Hey
k6　<= 今回話したいのはこのツール
JMeter
Locust
nGinder
Siege
Salvo
Taurus
Tsung
wrk
※k6のロゴ+自分が知ってるツールを付け加えた

その中であえてk6を選択するのか？

プロダクトの開発頻度
使い勝手(ユーザービリティ)
性能
負荷試験中に要求されるリソース
実現できること/できないこと

など、詳細なセルフレビューで技術選定ポイントをアピールしたわけです。負荷試験は自分の得意な分野ではないので正直あまり詳しくないのですが知ってる人には突き刺さったと聞きます。

ベストプラクティスを求めて新技術を追いかけるのは簡単ですが、情報感度を一段上げるためにも、今解決したい課題について軸足をもつとなおいいと思います。

それが現在はっきりしなかった場合は、このプロダクトをどうして開発したのか？書かれたデザインドックやモチベーションノートを見れば、意外とあちらからやってくるかもしれません。

ベストプラクティスから外すために

ベストプラクティスにジョインするものもあれば、リリース、外されるものもあります。PJでの採択数が自然減に生じたことを受けて...といったプロセスで外されるわけですが、そこで重要視しているのが技術が生まれた時代背景です。

例えば、運用監視・モニタリングなどは主たる例でしょう。

ITサービスのメトリクスは安定的な運用目的のために昔から取得されてきた情報ですが、
その取得方法やアーキテクチャには大きな変化がありました。

「モニタリングシステムの Push 型 Pull 型アプローチと Prometheus についての考察」

をベースに話をしたいと思います。

運用監視・モニタリングソフトウェアはどうやってデータを取得しているか？
Pull型 or Push型という対立軸があります。

このトレンドが変換する要因となったアーキテクチャ遷移の理由は二つあります。

アーキテクチャトレンドが変わった時代背景その1として、ざっくり昔と比較して爆発的に運用監視対象のサービスが増えたんですね。時代を遡りますと

2006年頃: AWSにS3登場
2014年頃: マーチンファウラーさんがマイクロサービスアーキテクチャを書き、有名に
2017年頃: IoTが最もグーグルで検索された年
など様々なイベントがあり、その結果、爆発的に運用監視対象のサービスが増えたために、リードタイムが比較的短いPush型やサービスディスカバリーというプラットフォームのエコシステムを活用したモニタリングシステムが好まれるようになりました。

また、DevOpsの登場で開発と運用の一体化が言われるようになったことも大きいです。

2008年～2009年頃にかけてDevOpsが有名になり、開発と運用の一体化が言われるようになりました。その結果、運用監視システムも運用チームだけが利用者だけではなくなった。またその目的も単純な運用監視だけではなくなく、パフォーマンス調査等にも活用されるようになりました。

結果としてアプリケーションやインフラの境界を越えて、様々なシステムの運用監視データを集約して一元的に管理したい。また表示内容もログ、メトリクス、APM、分散トレーシングと多岐にわたるようになり...運用監視を自社で保守しきれない!!SaaSが好まれる下地になりました。

それでは、旧来型のPull型は消えたのでしょうか。いいえ！！GoogleはPull型のBorgmonを捨ててPush型のMonarchに移行しましたが、(単純な話ではないですが...)、Borgmonをベースに開発されたPrometheusは、Borgをベースに開発されたKubernetesとエコシステム上で融合して独自の発展を遂げました。監視対象リストを自動更新するサービスディスカバリー機能搭載やFederationを備えた拡張パック(Cortex, Thanos)により、弱点をカバーするようになったのです(※tsdb等永続層管理で課題あり)また、オンプレミス・インフラストラクチャー界隈では、サービス運用監視対象が落ちたことを確実に検知できるPull型が依然として好まれている実態があります。ですがその市場はクラウドに押されてユーザー企業からは遠い世界になりつつあります。

そして今。SREというゲームチェンジャーの登場で、SLO Monitoringというジャンルであったり、4 key metricsといった新しい指標が生まれています。つまり、従来の運用監視やトラブルシューティングだけではなく、新しい開発を積極的に行っていくための指標として運用監視・モニタリングソフトウェアが活用されつつあるんですね。

このトレンドの変化により、また大きな変化が今後生じるのではないでしょうか。

...と、長々と運用監視サービスの話をしてきましたが、これらを俯瞰して言えるのは運用監視サービスのアーキテクチャトレンドの変化はシステム界隈やビジネス成長に合わせた年輪であることです。

捨てたくないという一心で積もりに積もったベストプラクティスの山は、ごみではなく会社が成長してきた歴史であります。ベストプラクティスとはビジネスモデルの過去、現在、未来がわかる断面でもあるのですね。捨てたくないお気持ちはわかりますが、現在から未来へ変えていくことが重要だと思います。

こんな感じでベストプラクティスのサービスが出た時代背景を逆引きすることで、自社のビジネスモデルと比較したベストプラクティスのズレやギャップにつなげられるのではないでしょうか。

まとめ

本日はベストプラクティス・ドリフトについて話をしました。

これはシステム開発だけではなく、わりと普遍的な事象だと思います。

根本的な心理として、今までうまくいっていたことを変えるのは抵抗感がありますよね。それを変えるための材料として客観的な指標はいくらでも集めることはできると思いますが、さらに一歩踏み出すために、技術への好奇心と変わり続けるマインドの両方を忘れないことが重要だと思います。

今回のセッションに当たって、社内の詳しい人にヒアリングを行ったんですが、先ほどの商用データベースから PostgreSQLに切り替えようという話について、当時を振り返った役員はこのような話をもらしてました。

うちの技術選定はテッキーによるピュアな判断ではない。テッキーによる経営戦略なんだ。

本日のお話で何か皆様にも持ち帰っていただければ幸いです。ご清聴ありがとうございました。

動画

https://youtu.be/4E0zHLc2DwQ

参考文献

Open source load testing tool review 2020

モニタリングシステムの Push 型 Pull 型アプローチと Prometheus についての考察

ソフトウェアのバージョンと開発スタイルの関係について