この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
「いや、そこまでAWSどっぷり使ってもうたら、他に移行するの大変やん？」
あなたがユーザー側クラウド導入推進担当として、あるいはクラウドベンダーの担当として上司やお客様から冒頭の質問を投げかけられた時、どのように答えますか？
自分もクラウドベンダーの一員としてお客様と対峙する時、基本的には「AWSにあるものは基本的に全て使いましょう。それが結局は一番オトクです」と答えているんですが、それがすべて本当なのか？AWSのなかでもマネージドサービス複数あるけど、使えば使うほどええってわけでもないのでは？と不安になり、このセッション聴講してみました。
結果、ロックインという概念の明確化とそれを議論するときの手法が非常に明確に解説されたセッションだったため、非常に学びが多かったです。是非、これは皆さんにも味わっていただきたいと思います。
（祭） ∧ ∧ Y ( ﾟДﾟ) Φ[_ｿ__ｙ_l〉 ﾛｯｸｲﾝ ﾏﾂﾘﾀﾞﾜｯｼｮｲ |_|＿| し'´Ｊ
セッション概要
セッションタイトル
「開発におけるロックインのリスク評価と考え方」
セッション概要
システム開発を進める上では様々な技術選定が必要となります。プログラミング言語やウェブフレームワークの選定といったものから、 クラウドのマネージドサービスを使うか OSS や有償のサードパーティ製品を使うかなど、技術的な選択は多岐に渡ります。このとき一般に懸念の１つとなるのが ロックイン（ベンダーロックイン） です。
選択した技術が開発の要件に沿わなくなってしまったときに他のプロダクトへの乗り換えの困難性を指す用語です。このセッションでは特にクラウドのサービスに対する ロックイン を、システム開発におけるその他の様々なリスクと並べて評価しロックインをどのように考えるべきかを整理していきます。
講演者情報
アマゾン ウェブ サービス ジャパン株式会社
ソリューションアーキテクト 畑 史彦 様
ソリューションアーキテクトとして、ゲームを開発されているお客様を主に担当しています。
記事中注意
本記事におけるスクリーンショットは、すでに公開されているセッション資料より引用させていただいています。リンクは、記事の文末にあります。
セッション冒頭
私はソリューションアーキテクトとしていろんなお客さんと話す機会があります。そのなかで、お客様と話せば話すほど、「ロックイン」という言葉は多く聞くんですね。今までのそういう経験を踏まえて、今回はセッションを作成しました。アジェンダはこちら。
- "lock-in"とはなにか
- Switching costsで考えるリスク評価
- ロックインのリスクを低減しつつかつ開発速度も向上させる
１．"lock-in"とはなにか
ひとつ、非常にわかりやすいロックインの状況を提示します。「あるベンダーの「製品A」を採用した。時間が経ち、別の「製品B」に変更したくなった。しかしそれができない。あるいは、多大な労力を要する。」なぜ、これがロックインと言えるのか？
「機能を手放すことができない。性能を手放すことができない。別システムインターフェース変えないといけない。ライセンスや契約に利用期間を縛られている。」状況だからです。
はい。これ、いわゆる「ベンダーロックイン」ですね。これを解消する方法ってありますかね？
- 特定のベンダーが提供するプラットフォームのリスクは大きい？
- オンプレミスなら解決するのか？あるいはマルチクラウド？
- ベンダーフリーなOSS製品だけを使う？
- そのOSSがメンテナンスされなくなったらどうするのか？
改めてロックインを考え直すと、ロックインには2種類あります。
ベンダーロックイン
ロックインというときはこれが多い。前で説明したような状況
プロダクトロックイン
- ベンダーロックインは大抵の状況ではプロダクトロックインにもなっている
- OSSでもプロダクトロックインは起きうる
- Cassandraを使い倒して何年も経ってデータ量も多い状態からHBaseに移行しようとすると、移行労力はどれぐらいあるか。この場合ベンダーは居ないけど、これも開発コミュニティにロックインしていると言える。
プラットフォームロックイン
単一の製品ではなく、プラットフォームの製品群やそのサービス全体に対するロックイン
アーキテクチャロックイン
- サーバーレスアーキテクチャをコンテナベースのアーキテクチャに変えるとしたら
- マイクロサービスとモノリスではどちらがアーキテクチャ変更しやすいか
例えばAmazon DynamoDBの採用は、ロックインのリスクがあり得るか？MySQL on EC2なら安心か？「MySQLというOSSプロダクトへのロックイン」という考慮は杞憂でしょうか？
ロックインに対する評価
どちらかの状態（ロックインする/しない）に綺麗にわけてリスクが存在するわけではない。その間には常にグラデーションが存在する。存在するのは、ベンダーやツールやサービスなどを乗り換えようとする際、乗り換えにかかるコスト→Switching costs
Switching costsが現実的な値を超えそうなとき時 → 「ロックインする」と表現される。
より正確にリスクを評価するには、2値のバイナリではなく、定量的に評価できるSwitching costsという考え方を導入するべき。
以下の資料が参考になる。
Switching Costs and Lock-In | AWS Cloud Enterprise Strategy Blog
「ロックイン」という用語は誤解を招きます。私たちは ただ switching costs の話をしています。 switching costs は IT の歴史を通じて常に存在していました。プラットフォームまたはベンダーにコミットすると、その瞬間 に、後から変更する場合の switching costs が生まれます。Java を選択してから Node.js に移行すればコストが かかります。(中略)そこには単に switching costs があるだけです。状況によってそのコストは大きくも小さく もなります。”
２．Switching costsで考えるリスク評価
ここで、一つの例をとって、Switching costsについて考えてみましょう。
「It's a Trap! Vendor Lock-in and the Cloud」
- Slide
- Video
このスライドで投げかけられている疑問がこちら。
- 私達のビジネスを全て学んで、 私達の仕事を奪う気だろ!
- そのサービスの提供が 突然終わるかもしれない
- 価格を不当に釣り上げて くるかも!
これらを単純にlock-inで評価するのではなく解像度を上げてswitching costsの観点で評価しましょう。
「１．そのサービスの提供が突然終わるかもしれない。」
これをtrue / Falseで評価してもしかたない。常にTrueになる。
例えば、ECSを例に取ると、以下の点きになりますよね？
- サービスを終了する可能性は？
- どの程度の期間における話なのか？
- そのゲームやサービスが5年続く可能性はどのくらい？システムの耐用年数は？
- switchする可能性はどの程度なのか
- ECSを使った場合に得られる利益はどの程度か？
- 競合がそれら利益を享受して鋭意開発を進めていたら？
- EKSを使えば将来のswitching costはさがるのか？
「２．価格を不当に釣り上げてくるかも！」
これも可能性の話をするならあるかもしれない。どれほどあり得るかのパーセンテージの試算は各自やる。しかし過去の実績含めて判断材料はある。
この会場にお越しのお客様はご存知だと思いますが、AWSは継続的にずーっと値下げを実施してきている。これは事実として参考にできるものです。
- クラウドのサービスを今日から使う？今その利益を享受して、後で代償を支払うのか
- クラウドのサービスを今は使わない？将来の潜在的な乗り換えコストを避ける代わりに、いますぐコストを支払うのか
switching costの考え方として重要なのは以下の点です。
- 可能性が低い乗り換えにおけるswitching costを加増に見積もりすぎないでください
- 実際の現実的な可能性や確率でかけ算してあげてください
- それによって失われるもののリスクも評価してください（言い換えれば、得られる利益）
また一つ、記事を紹介します。
- Gregor Hohpe
- Don't get locked up into avoiding lock-in
3. ロックインのリスクを低減しつつかつ開発速度も向上させる
Switching costsを低下させるだけでなく、開発そのものにも利益を生むような投資はないのか、と考えた場合、あなたのシステムの利益を生むような投資先にとして、以下の4点が挙げられる。
- 技術的負債と向き合う
- CI/CDパイプライン
- Infrastructure as Code
- 疎結合なアーキテクチャ
1. 技術的負債と向き合う
サービスやソフトウェアを変更しようとした際に最もハードルとなるのが、現在採用しているサービスやソフトウェア自体による制約よりもそれらを利用している側のコードの技術的負債であることは多々ある。
- 時間がないためにチェックインされたアドホックな修正
- 忘れ去られる多数のモンキーパッチ
- 1人しか把握していないコード
- 単体テストがない、負荷テストは1st launch以来やっていない
Switching costsが負債なら、技術的負債はより包括的な負債。Switchだけでなく、日々の開発にも大きな影響を与える変数となる。基本的には、単純に技術的負債に向き合い開発のvelocityを上げることが、switching costを含む多くの課題を包括的に解決していく。
2. CI/CDパイプライン
- 継続的インテグレーション
- 継続的デリバリ（デプロイメント）
- ソフトウェア（コード）の変更コストを下げる
サービスにしろミドルウェアにしろ、移行に際してコードの修正や対応が不要であることはまず無い。むしろコード側が柔軟に対応できる状態であればswitchの選択肢は広がる。
3. Infrastructure as Code
- インフラストラクチャ全体をプログラミング言語やJSON,YAMLなどでモデル化
- 繰り返し可能な方法でリソースをプロビジョニング及びデストロイ
インフラストラクチャ全体をプログラミング言語や、YAMLで定義できる。
4. 疎結合なアーキテクチャ
疎結合なアーキテクチャは、アーキテクチャの変更コストが低い。サービスやミドルウェアを変更する際にアーキテクチャに影響が及ぶことがすくなくない。
- キューによる非同期化
- コンテナ化によるホストOS環境との分離
- Service Discovery（Cliend side Service discovery）
- LB（Server side Service discovery）
- サービスメッシュ
- Microservices
まとめ
- lock-inの形態と程度は多様
- lock-inするしないの2値で雑にあつかわない、思考停止しない
- switching costsとして定量的に捉えるのが非常に重要
- （switchにかかる費用 ✕ switchの発生確率） - switchしなかった場合に享受できる継続的な利益
- 開発上のそしてビジネス上のリスクはlock-in意外にも様々ある
- リスクヘッジの投資のROIを意識
- 技術的負債と向き合い普遍的な開発力向上に投資を。多数のツールを飼いならすことに投資するのではなく、素晴らしいツールを使い倒すことにリソースを投下すること
濱田感想「ロックインリスクに対する考え方が引き上げられて気分爽快！！」
一言そんな感じなんです。今まで「ロックイン」というネガティブなキーワードを目の前にしたときに、その単語のネガティブな印象が強すぎる、かつ自分が立場上AWSをがんがん使っていこうぜ！という場合が多いため、どうしても自分の思考も大雑把になることが多かったなと反省しています。
「まぁ、まぁ大丈夫ですよ。AWSですからね。世界最大シェアですし。乗るしかねぇ、このビッグウェーブに！！」ぐらいの大雑把加減です。あかんやろ。
そういうモヤモヤポイントを、解像度を高く真正面から捉えて、2元論ではなくswitching costという定量的なもので、それらの技術を採用することのメリット、さらに採用しなかったことによる得られたであろうメリットにまで思いを馳せて議論していくという考えが非常に新鮮でした。
もちろんそうやったとしても、数字が綺麗にドーンと出て、「こっちでやりましょ！」と綺麗に片付くわけではないとも理解していますが、まずは同じ目線で顧客と話す余地が深くなったことに、非常に学びが有りました。
また、「3. ロックインのリスクを低減しつつかつ開発速度も向上させる」の章も非常に参考になりました。ここまで含めてのシステム全体のTCOであり、「投資するなら、一番効果が高そうなところをきちんと見極めていこう」という前向きな手法が紹介されていたので、ベンダーロックインという文脈のなかでもここまで包括的に議論するべきだなと視野が広がりました。
セッション全体非常に学びが多く、新しい視点を開かせてくれる最高の時間でした。是非、資料も公開されているので、ロックインに関するモヤモヤを抱えている皆さん、参考にされてみてはと思います。
「いや、そこまでAWSどっぷり使ってもうたら、他に移行するの大変やん？」
皆さんならどう答えますか？それでは、今日はこのへんで。濱田（@hamako9999）でした。
AWS DevDay Tokyo 2019のセッション資料
AWS DevDay Tokyo 2019セッションのうち、公開を許諾された資料は以下に掲載されています。
0
