クラウドサービス利用者につきまとう「ベンダーロックイン」問題にはどう対処するべきなのか？

Amazon Web Service(AWS)やMicrosoft Azure、Google Cloud Platformなど、クラウドサービスが普及することで、自前のサーバーがなくてもウェブビジネスを展開できる時代になりました。そんな中、Slackでチームの休暇を簡単に管理できるアプリのベンダー「Vacation Tracker」が、クラウドサービスにおけるベンダーロックインについて解説しています。

Fighting vendor lock-in and designing testable serverless apps using hexagonal architecture - Vacation Tracker
https://vacationtracker.io/blog/big-bad-serverless-vendor-lock-in/

「ベンダーロックイン」とは、ユーザーが特定のベンダー(メーカー)に依存した結果、切り替えるためのコストを支払わなければ他のベンダーに移行できない状態をいいます。

例えば、あるユーザーがサーバーを借りたとします。ユーザーはこのサーバーを「クラウド」と呼び、ストレージやコンピューティング、機械学習などに応用します。サーバーの貸主は他にも大量のサーバーとユーザーを抱えていて、ユーザーがサーバーを使った分だけ使用料を徴収します。

しかし、ユーザーがクラウドサービスを受け入れて各自のビジネスロジックへ本格的に実装した頃合いで、サーバーの貸主が使用料をめちゃくちゃ値上げする可能性もあります。

仮に、他にも大量のサーバーを抱える貸主がいたとします。この貸主が提供するクラウドサービスでもコンピューティング、ストレージ、機械学習など、さまざまな用途にサーバーを応用できます。新しく登場したクラウドサービスは、今使っているクラウドサービスよりも安く、ユーザーが開発したアプリやサービスも動作する可能性があります。

それではクラウドサービスを移行すれば解決するのかというと、事はそれほど簡単にはいきません。従来のクラウドサービスと新しいクラウドサービスでは当然動作環境が異なるため、移行してこれまで通りに運用するには、環境移行に伴う調整とテストを行う必要があります。また、今までぶつかってきた問題をクリアするためにその場しのぎで行った対応が、サービス移行の際に大きな障害となって立ちはだかることも。サービス移行にかかるスイッチングコストを考えた結果、「使用料が高騰していても従来のままで運用していくのがよい」と判断する場合が往々にしてあるというわけです。

しかし、クラウドサービスそのものに問題が生じた場合、移行が困難なままであれば、結局はアプリケーションそのものが立ちゆかなくなってしまう可能性もあります。

ベンダーロックインは「Lock in(固定)」という言葉から、一度はまってしまうとベンダーを一切変更できないように考えてしまいがちですが、これは単にスイッチングコストの問題でしかないと、Vacation Trackerは指摘。Amazon Web Service(AWS)のエンタープライズストラテジストであるマーク・シュワルツ氏も「Switching Costs and Lock-In」という記事の中で、「『ロックイン』という用語は誤解を招くと考えています。本当に議論しているのはスイッチングコストについてです」「スイッチングコストはこれまでのITの歴史上でも存在しました。プラットフォームやベンダーを後から変更しようとすると、スイッチングコストが発生します。例えば、Javaを選んでからNode.jsに移行するとコストがかかります」と述べています。

Vacation Trackerは、クラウドサービスのベンダーロックイン問題を解決するということは、すなわち「いかにしてスイッチングコストを低く抑えることができるか」に直結すると論じています。そして、スイッチングコストを低く抑えるための方法の1例として、「ヘキサゴナルアーキテクチャ」を採用した設計を紹介しています。

ヘキサゴナルアーキテクチャは「データベースや外部サービスが、アプリケーションにアダプターを介して間接的に依存する」というもので、ビジネスロジックを持つアプリケーションそのものはどこにも依存しないという設計思想。ヘキサゴナルアーキテクチャを取り入れることで、特定のインフラに依存しないアプリケーション開発が可能になるとVacation Trackerは述べています。

例えば、Vacation Trackerは単体テストと統合テストを行ったMongoDBのリポジトリを使っていたとのこと。しかし、DynamoDBへの移行が決まったので、アダプタとなるdynamodb-repository.jsを作成して呼び出したそうです。このリポジトリはMongoDBのものと同じインターフェースを持ちます。移行中はサービスを2つのリポジトリに同時に接続し、再構築していきました。最終的に移行が完了したら、MongoDBのインテグレーションをサービスから削除すればOKというわけです。

Vacation Trackerの休暇申請アプリは「ヘキサゴナルアーキテクチャを使用したテスト可能なサーバーレスアプリケーション」として設計されていたため、スイッチングコストも低く抑えることができたというわけです。Vacation Trackerは「スイッチングコストを低く抑えるためには、アプリケーションの計画から考えなければなりません。そして、アプリケーションをアップデートしながら、将来必要となるであろう移行のコストがかからないようにするために、いくつかの優れたアーキテクチャの実践やソフトウェアデプロイメントを検討する必要があります」と述べています。