注意書きここから
注意書きここまで
アーキテクチャに関係する労力の大部分は、ロックインを軽減したり避けたりすることに費やされています。 結構壮大な目標です。なぜならアーキテクチャは選択肢を与えてくれるもので、ロックインはその反対を意味するからです。 ですが、ロックインは単純に白黒つけられる問題ではありません。 ロックインを回避しようとするため別の何かに縛られてしまう場合もあるからです。 また、一部ではOSSが魔法のようにロックイン問題を解決してくれるなどと言われていますが、完全に間違っています。 ロックインについて詳しく理解する時間を設けるようにすれば、回避すること自体に縛られてしまうことを避けられるでしょう。
アーキテクトの主な目的の1つは「選択肢を作る」です。 選択肢があるとシステムは変更に強くなります。 私たちはより多くの情報が得られるまで、あるいは予期せぬ出来事に対応しなければならなくなるまで決定を先延ばしにできるのです。 「ロックイン」は真逆の状態をもたらします。 あるソリューションから別のソリューションへの変更を困難にしてしまうのです。 だから多くのアーキテクトは相互接続可能なコンポーネントを自由に交換できるITシステムの世界を守る守護者としてロックインを敵視するのです。
しかし、単純なままでいられるアーキテクチャはほとんど存在しません。 ビジネスとのトレードオフがあるからです。 経験豊富なアーキテクトなら、ロックインにはそれを回避しなければならないという一般的な意見よりずっと奥深い何かがあることを理解しています。 ロックインにはさまざまな側面があるし、中には素敵なソリューションとして採用できるものすらあるのです。 そういうわけで、ロックインについて詳しく理解するため「アーキテクトエレベーター」に搭乗してみましょう。
私たちがソフトウェアをデプロイするようになった、かつてないほどに強力で近代的なクラウドプラットフォームは、アップロードした写真が子犬かマフィンか見分けるだけでなく、ソースコードをコンパイルしたりその結果をデプロイしたり、必要なインフラを構成したり、私たちのデータを格納したりします。 この素晴らしい利便性と生産性の加速装置は、今までにない新しい形態のロックインをもたらします。 近年多くのアーキテクトの注目を集めているハイブリッドあるいはマルチクラウドの構成は、新しい種類のロックインについて考察するちょうどいい例になります。 まず、クラウドプラットフォームにデプロイしたいアプリケーションがあることにしましょう。 やることは簡単ですが、アーキテクトとしての視点にはさまざまな選択肢が見えているでしょうし、特にロックインに関係するより多くのトレードオフも見えているでしょう。
アプリケーションをコンテナにデプロイしたいと思うかもしれません。 いいことですね。ですが、そのためにAWS ECSを使わなければならないのでしょうか。 それってAWSのプロプライエタリサービスですよね。 Kubernetesのほうがいいですか。 OSSですし、オンプレミス環境を含むたいていの環境で実行できますよね。 それで問題は解決するんですか。 たぶんなんですがKubernetesマニフェストのYAML地獄で混乱しているんじゃないですか。 要するに、あなたはロックインと別の何かを交換条件にしたんですよ。わかってますか。 また、Google GKEやAmazon EKSや Azure AKSなどのマネージドKubernetesサービスを使っているなら、Kubernetesのバージョン依存やプロプライエタリの拡張機能に悩まされているかもしれませんね。
オンプレミス環境でソフトウェアを実行しなければならないとしたら、AWS Outpostsを利用することもできるでしょう。 そうすればいろんな選択肢が利用できます。 ただ、繰り返しになりますがそれはプロプライエタリ製品です。 あなたがかつてロックインされていたであろうVMWareと統合するとして、これまでとどんな違いがあると言うのでしょうか。 Googleもほとんど同じことをする新しいサービスのAnthosを提供しています。こちらはOSSコンポーネントで構築されているのですがプロプライエタリ製品として導入するしかありません。 それでも、Anthosを維持している限りアプリケーションを別のクラウドへ移行できるのです。 これってロックインの定義そのものじゃないですか。
たとえ自動化したデプロイの仕組みから、アプリケーションの実行環境をきれいに分離できているとして、ロックインに関するあらゆるコストを相殺するほどインフラストラクチャの切り替えが簡単にできるわけではありません。 世の中にはクロスプラットフォームに対応したIaC（Infrastructure-as-code）ツールもありますが、そういう懸念を解消してくれるわけではありません。
ストレージが必要になったらAWS S3を使うんですか。 他のクラウドプロバイダーもS3と互換性のあるAPIを提供しているので、たとえプロプライエタリ製品であってもS3はマルチクラウドに対応したロックインフリーだと言えるでしょうか。 結局ストレージへアクセスする抽象化レイヤを設けて、それぞれの依存先ごとに実装を用意することになると思うのですけど、それが賢い方法なんでしょうか。
どう考えてもロックインの回避は困難を極めることになりそうですし、それだけでいっぱいいっぱいになってしまいそうです。 著者はもう少しクラウドアーキテクチャの楽しさに浸っていたいので、サイモン・ウォードレイの紹介しているハイブリッドクラウドに向かうのはもう少し後にしようと思います。
https://twitter.com/swardley/status/908031162668474368
エレベーターに乗ったアーキテクト（登ったり下ったりするアーキテクトエレベーターに搭乗している人）は、大半の人には白と黒しか見えないところへ影を見出すことができるようになります。 システム設計について考えているなら、ロックインや結合のように一般的な特徴は2値で表せないことに気づくのです。 2つのシステムは単純に結合したり分断したりするわけではないのと同様に、単純になんらかの製品へロックインしているわけではないのです。 それぞれの特徴には多くの微妙な意味合いがあります。 例えば、ロックインなら次のようにいろいろな側面へ分解できます。
まとめると、ロックインは全部かゼロかという判断からは程遠いものです。 それゆえに、さまざまな側面を理解すればより意識的に意思決定できるようになるのです。 この一覧はOSSが魔法のようにロックインを解消してくれるという間違った幻想を打ち砕くものです。 OSSはベンダーロックインを軽減してくれるかもしれませんが、他の種類のロックインはそのままです。 だからといってOSSが悪いわけでもなく、ロックインを取り除く魔法なんてないんだよということです。
経験豊富なアーキテクトは白と黒の混ざった部分を見分けるだけでなく、意思決定のための優れた規律に従っています。 私たちは自分で思っているより意思決定者としては凡庸なので、（規律に従うことは）重要です。 信じられなければダニエル・カーネマンのThinking, Fast and Slowを読んでみるといいでしょう。 モデルを利用するのは意思決定のためのより良い方法の1つです。 特に単純なモデルでさえ驚くほどの効果を発揮するのです。
単純でも感情に訴えかけるモデルは優秀な科学者の証です。しかし、過剰に洗練されているとかパラメータ化をやりすぎているモデルは月並みな能力しかないことを示しています。 -- George Box
経営コンサルタントも愛用する有名な2次元のマトリクスを笑い飛ばすべきではありません。 自分たちもいつか発見するかもしれない簡潔で効果的なモデルの1つなのですから。 モデルについてもう1つ重要な点があります。 一般的に言われているように、不確実性に向き合っているときは「考えずに衝動的に行動しなければなりません（shoot from the hip）」。結局のところすべては流動的なのです。 もちろん正反対の意見もあります。 基本的に私たちの愚かな意思決定がより悪い結果をもたらすのは、多数の相互依存性を扱わなければならないとか、不確実性が高いとか、成功する可能性が低いとかそういう場合だけです。 そういうときモデルを活用すれば、意思決定のためにより適切な構造や規律を整えることができるでしょう。 ロックインの落とし穴に飛び込んでみるとして、どれくらいまで許容するか判断する問題はこの議論の範疇に含まれます。 というわけでモデルを活用していきましょう。
簡潔なモデルを利用すると「ロックイン=悪」という思考停止の罠を避けられるようになります。 まず、私たちが認識しなければならないのは、何者にもロックインされないでいるのは困難であるという事実です。 ある程度のロックインは避けられないのです。 次に、私たちはある程度のロックインを許容することで相応の利益が得られるならたぶん幸せになれます。 例えば、競合製品にない独自機能や独自の使い方がある場合など。
それぞれの要因を2次元マトリクスという簡単なモデルで考えてみましょう。
このマトリクスの縦軸（切り替えコスト）と横軸（独自機能）は次のような意味です。
そうするとそれぞれの4象限は次のように考えることができます。
簡潔なモデルにソフトウェアコンポーネントを配置してみるのはいい実験になります。 あなたの理解を可視化するだけでなく、さまざまなステークホルダーに対するあなたの決定を伝えてくれるからです。
普段使っているソフトウェアをマトリクスに配置してみると、いろいろなモノについてさまざまなロックインの度合を判断をしているのが分かるでしょう。 右上から反時計回りに説明しています。
「独自機能」という言葉について注意点があります。 あらゆるベンダーは何らかの独自機能を提供しているはずです。それが差別化の方法だからです。 ですが、今はそういった機能をあなたに提供する独自の価値や、具体的な機能へ変換した前提で議論しています。 例えば、あるクラウドプロバイダーが地球規模のネットワークで1億人規模のユーザーがいるサービスを提供していることにしましょう。 それはそれで素晴らしいことなのですが、100万人の顧客が対象であるとか、単一の国へ限定したサービスであるとか、そういう平均的なエンタープライズシステムにとって役に立つ可能性は低いのです。 国土は狭いし速度制限もあるような国でフェラーリを購入するような人もいるのですが、あらゆる意思決定が合理的でなければならないわけでもありませんし、たぶんクラウドプラットフォームよりはいろいろと役に立つ場面があるのでしょう。
単純なマトリクスが便利なのは分かってもらえたと思うので別の例を見てみましょう。 前の例では「切り替えのコスト」を軸にしていました。 優秀なアーキテクトはそれをさらに2つの軸へ分割できます。
このマトリクスは、切り替えのコストと、切り替えが必要になる可能性の関係を示しています。 切り替えが必要になる可能性は低いし、コストも低い要素は特に問題にならないはずです。 一方、対角線上に位置する、切り替えが必要になる可能性が高く、高コストな要素は良くないので何かしら対応しなければなりません。 コストはかかるけど切り替えが必要になる可能性が低い要素を選択するなら、変更スコープを制限するとか、保守費用を割り増しにするなどの保険をかけたくなるはずです。 リスクを引き受けないといけない場合もあるでしょう。 実際にOracleからDB2へ移行しなければならない場合がどれほどあるというのでしょう。 切り替えが必要になる可能性は高いけど、コストは低い要素では「アジリティ」を実践することになるでしょう。 変化を受け入れながら低コストで実行できるシステムを設計するのです。 おかしな話ですが、「アジリティ」は「ギャンブル」と比べて小さな変更を頻繁に追加できるにも拘わらず注目されにくいのです。 それは私たちが凡庸な意思決定をしているせいでもあります。 ドラマが注目を集めるのは次に何が起きるのか分からないからなのです。
ロックインの可能性について議論していると、切り替えのためのいろいろなシナリオを検討したくなるものです。 ベンダーが事業をたたんでしまうとか、値上げするとか、あなたのシステムの規模や機能に見合うサポートを提供しなくなるとか。 面白いことに、ロックインを軽減したい気持ちはある種の交渉における道具になります。 ライセンスの更新について交渉するとき、自分たちのシステムは他の製品への切り替えは簡単に安価に実現できるアーキテクチャになっているんだよと、ベンダーの担当者に教えてあげることもできるのです。 あなたたちのBATNA（Best Alternatives To a Negotiated Agreement）を伝えることで値引き交渉を有利に進められるようになります。 これはアーキテクチャとしての選択肢であって、実際にそうするとは限りません。 冷戦下における備蓄兵器のように抑止力として働くのです。 本当にロックインを軽減できているわけではなくても嘘をつくことは可能です。 ただ、ベンダーが嘘を見抜くこともあるので、休憩時間にウォーターサーバーの周辺で開発者とおしゃべりでもして狡猾なポーカープレイヤーになるのを目指しましょう。
著者らの書いたオプション売買のアナロジーをもう一度最初から読み直してみてください。 ロックインの回避がオプションに相当するとしたら、切り替えのコストはオプションの行使価格と考えられるのです。つまり、オプションを行使するときに支払う価格ということです。 行使価格が低ければ切り替えのコストは低いことになるし、高ければ価格よりオプションの価値が高くなるということです。 すべてのシステムが切り替えコストを最小化する「緑の範囲（green box）」に収まっているのが一番ですが、必要な投資が実際に報われるかは別の話です。
例えば、多くのアーキテクトはデータベースベンダーやクラウドプロバイダーにロックインされることを嫌がります。 ですが、実際に切り替えが必要になる可能性はどれくらいあるというのでしょうか。 5%でしょうか、もっと低いかもしれません。 手作業を含む切り替えのコストを$50,000をできるだけ0に近づけて欲しいと言われたらどうしますか。 ほとんどの場合、節約できる費用の期待値は$2,500($50,000*5%)より大きくなるでしょう。 だから切り替えのコストを最小化することを単独の目標にするべきではありません。すぐ過剰投資になってしまうからです。 保険金をかけ過ぎるのと同じです。税金の控除額が0へ近づくことに関心が向くかもしれないけど、たいていの場合それは経済的な得になりません。たとえそれが合理的な判断であったとしても。
最後のモデル（マトリクスじゃないけど）は切り替えのコストを減らすためにどれだけ投資すればいいのか判断するのを助けてくれます。 次のグラフでは、青の曲線で負債（前払いの投資額に応じた切り替えの発生する可能性と、製品の切り替えコストを掛け算した値）をプロットしています。
オプションに投資すると負債が減少するのは明らかです。切り替えの可能性が低下する場合もありますし、行使価格が低下する場合もあるでしょう。 例えば、HibernateのようなORMフレームワークを採用することは、データベースベンダーへのロックインを軽減する小さな投資になります。 データベースの固有のストアドプロシージャへ変換するメタプログラミング言語を作成することもできるでしょう。 そうすればロックインを避けながらデータベースの性能を十全に活用できるようになるのですが、事前の投資が必要になるためあり得そうにないシナリオです。
総額（前払いの投資額と潜在的な負債を足し算した値）をプロットした赤の曲線は面白い特徴を示しています。 あなたが最小化しなければならないのはこの総額です。 ほとんどの場合、前払いの投資額が増えると最適区間に移動していきます。 ロックインを回避するための投資を追加すると、総額は上昇していきます。 理由は簡単で、切り替えが必要になる可能性も低下するため投資に対する見返りが減少するからです。 他で見ないほどアーキテクチャを柔軟にするとしたら、過剰投資の区間に入ってしまうでしょう。 Yagniの信奉者はその対極（過少投資）に位置することでしょう。 ありきたりの考え方になりますが、中庸を保つことが成功の秘訣です。
さて、私たちはロックインについてコストや潜在的な支払額がどうなるかいい感じに理解できたでしょう。 次は「ロックインを回避する」ための合計コストについて詳しく理解していきます。 前のモデルではロックインを回避するためのコストを単純にモデル化していましたが、もう少し細かく分割できるのです。
ロックインを回避するためのコストを計算するとき、アーキテクトは見落とすことが無いようにこれらの一覧をすぐ書き出せるようにしないといけません。 また、ロックインの回避は漏れの多い抽象化そのものであることを十分に認識しなければなりません。 例えば、Terraformはいいツールですが利用するスクリプトにはさまざまなベンダー固有の要素が登場します。 実装の詳細はそういう風に「漏れてくる」のです。 ですから、別のクラウドプロバイダーへの切り替えコストは決して0にならないのです。
いろいろ理屈を説明してきたので、この節では具体例を紹介します。
アプリケーションコードをDockerコンテナにパッケージングしてAWS ECSへデプロイしている会社で働いていることもありました。 つまりAWSにロックインされていたのです。 KubernetesのようにOSSのコンテナオーケストレーターへの切り替えに投資するべきでしょうか。 その時はサービス開発のベロシティが中心的な関心事で、ECSは十分に上手く機能していました。 だから著者は移行しても得はないと考えました。 他のクラウドプロバイダーへの切り替えが必要になる可能性は低いし、「もっと大切な仕事があった（bigger fish to fly）」があったのです。
助言：ロックインを受け入れましょう。
多くのアプリケーションはいくつものベンダーやOSSが提供するRDBを利用します。 SQL方言やストアドプロシージャ、専用の監視コンソールなどがロックインに関係してきます。 ロックインを避けるためにどれくらい苦労するべきでしょうか。 ほとんどのプログラミング言語や実行環境には、低コストである程度のデータベース非依存性を保証する汎用的なマッピングフレームワークがあります。 将来的な行使価格を最小化したいなら、SQL関数やストアドプロシージャを諦めましょう。 製品としての性能は低下するかもしれませんし、他の部分にかける時間も長くなるかもしれませんが。
助言：ロックインを避けるためにあまり苦労しない仕組みを使いましょう。切り替えコスト0を目指してはいけません。
データベースベンダーを切り替えるより、アプリケーションと一緒にクラウドへ移行することのほうが気になっていると思います。 技術的な考慮事項はいろいろあるけど、ベンダーとのライセンス条項によっては経済的な不利益を被る場合もあるので注意が必要です。 そういうときはOSSのデータベースを使うほうが賢い選択でしょう。
助言：運用やサポートができるならOSSデータベースを選択しましょう。それはそれで一定のロックインを許容することになりますが。
多くのエンタープライズが移植性のあるマルチクラウドデプロイに魅力を感じています。 また、かつてないほど綿密で複雑で費用のかかる計画の存在が、クラウドプロバイダーによるロックインから表面的に自由を獲得できているかのように見せかけています。 ただ、そういう計画のほとんどはあなたたちがクラウドへ移行したかった理由（ストレージやデータベースなどをマネージドサービスとして抵抗なく使えるようになりたい）を否定します。
助言：注意してください。著者によるマルチクラウドの解説も読んでください。
ロックインについてすごい時間をかけて考えてしまう人もいます。 私たちのような考え方を「アカデミック」であるとして敬遠する人もいます。 「アカデミック」を何か悪いことのように言われていることが何回もありますが、ほとんどは学校で習ってきたことばかりです。 それなのに、従来の白か黒で二分するやり方でアーキテクチャをより簡潔に、場合によっては効率的にできるというのでしょうか。
人間の思考は極めて高速に行われています。 この記事で紹介したモデルに全て目を通すだけなら数分もかからないはずですし、それだけで根拠のあるよい決定を下せるようになります。 適当なスケッチをする必要もありません。 高速なアーキテクチャとしての思考に必要なのは集中力なのです。
何週間も先まで定期的に開催することが予定されている、情報を得たところでまともに意思決定できない人たちが参加する長時間のステアリングコミッティミーティングのため、事前にスライドを推敲する労力と比べてみてくさい。
エレベーターに乗る選択をしたアーキテクトには、ミーティングの待ち時間をいろいろなことを考えるために使うことをお勧めします。
