LESSON 30分

ストーリー

田
田中VPoE
棚卸しの方法を学んだ。次はベンダーロックインについて深く理解しよう。「ロックインは悪」と短絡的に考える人がいるが、実態はもっと複雑だ
あなた
ロックインにも良いロックインと悪いロックインがあるということですか？
あ
田
田中VPoE
正確に言えば、「意図したロックイン」と「意図しないロックイン」がある。例えばDynamoDBを使っているのは、そのパフォーマンスとスケーラビリティが要件にぴったりだから使っている — これは意図した選択だ。一方、気づいたらCloudFormationに全IaCを依存していて、他のクラウドに移行しようにもインフラコードを全部書き直さなければならない — これは意図しないロックインだ
あなた
なるほど。ロックインの種類と深さを評価する必要があるんですね
あ
田
田中VPoE
そうだ。そしてロックインには「脱出コスト」がある。そのコストとロックインのメリットを天秤にかけて判断するのが戦略だ

ベンダーロックインの6つのレイヤー

レイヤー分類

レイヤー説明ロックイン例脱出難易度
インフラコンピュート、ストレージ、ネットワークEC2の特殊インスタンスタイプ依存、Nitro Enclave低〜中
データデータベース、データ形式、データ量DynamoDBのデータモデル、Redshift固有SQL中〜高
プラットフォームマネージドサービス、PaaSLambda、API Gateway、Step Functions連携高
アプリケーションSDK、API、ランタイムAWS SDK直接呼び出し、boto3密結合中
運用監視、IaC、CI/CDCloudFormation、CloudWatch Insights中
契約割引契約、コミットメントReserved Instances、Enterprise Discount Program低〜中

ロックインの深さの可視化

ロックイン深度マップ（例）:

サービス          深度  理由
────────────────────────────────────
EC2 (コンテナ)    ▓░░░░  コンテナ化済みで移行容易
S3               ▓▓░░░  S3互換APIが他社にもある
RDS (PostgreSQL) ▓▓░░░  標準RDBMSで移行可能
DynamoDB         ▓▓▓▓░  固有データモデル、移行にはスキーマ再設計
Lambda           ▓▓▓░░  コード自体は移行可能だが、トリガー連携の再構築が必要
Step Functions   ▓▓▓▓▓  固有のワークフロー定義言語、代替には完全な書き直し
CloudFormation   ▓▓▓▓░  AWS専用IaC、Terraformへの変換が必要
Cognito          ▓▓▓▓░  認証フローの再構築が必要
API Gateway      ▓▓▓░░  設定の移行が必要だが代替はある
CloudWatch       ▓▓░░░  標準メトリクスは汎用監視ツールに移行可能

ロックインの評価フレームワーク

LACE評価モデル

評価軸内容評価基準
Level（深さ）ロックインの技術的な深さ1: 表層的（設定変更で対応） 〜 5: 根本的（全面書き直し）
Area（範囲）ロックインが影響するシステムの範囲1: 単一コンポーネント 〜 5: システム全体
Cost（コスト）ロックインから脱出するためのコスト1: 数十万円 〜 5: 数億円以上
Effort（期間）ロックインから脱出するための期間1: 数日 〜 5: 1年以上

スコアリングの例

サービスLevelAreaCostEffort合計リスク判定
EC2→コンテナ12126低リスク
RDS PostgreSQL23229低〜中リスク
DynamoDB434415高リスク
Lambda + API GW343313中〜高リスク
Step Functions534517極めて高リスク
CloudFormation453315高リスク

リスク判定基準

合計スコアリスクレベル推奨アクション
4-7低現状維持。定期的なモニタリングのみ
8-11中代替手段の調査を開始。抽象化レイヤーの検討
12-15高移行計画の策定。段階的な脱却を推進
16-20極めて高即座に対策を実施。経営判断として意思決定

意図的ロックインの判断基準

ロックインを受け入れるべきケース

条件理由例
圧倒的な技術的優位性代替手段では得られない機能があるDynamoDBの単桁ミリ秒レイテンシ
開発生産性の大幅向上構築・運用コストが大幅に削減されるLambda + API Gatewayによるサーバーレス
コスト効率が明確自前構築より大幅に安いAurora Serverlessの自動スケーリング
短期間のプロジェクトロックインの影響期間が限定的PoCやキャンペーンサイト

ロックインを避けるべきケース

条件理由例
中核ビジネスロジックビジネスの根幹がクラウドに依存する課金エンジン、在庫管理コア
大量データの蓄積データ移行コストが時間とともに増加数PBのデータレイク
規制要件将来の規制変更で移行を強いられる可能性金融データ、医療データ
長期運用システム5年以上の運用でクラウド環境が変化する可能性基幹システム

ロックイン軽減のテクニック

抽象化パターン

パターン適用場面実装例
ポートアンドアダプターデータベースアクセスRepository Interfaceを定義し、DynamoDB/CosmosDB等の実装を差し替え可能に
抽象ファクトリクラウドサービス呼び出しCloudStorageFactory → S3Adapter / GCSAdapter
設定駆動環境差分の吸収環境変数やConfigでクラウド固有の設定を外出し
マルチクラウドIaCインフラ定義Terraform、Pulumiによるクラウド非依存のIaC

ただし、抽象化レイヤーを入れるとコストと複雑さが増す。“必要な箇所だけ”に抽象化を適用するのが鍵だ。

まとめ

ポイント内容
ロックインの6レイヤーインフラ、データ、プラットフォーム、アプリケーション、運用、契約
LACE評価モデルLevel・Area・Cost・Effortの4軸でロックインリスクを定量評価
意図的 vs 意図しないメリットが明確ならロックインを受け入れる判断もある
軽減テクニック抽象化パターンで必要な箇所だけロックインを緩和する

チェックリスト

  • ベンダーロックインの6つのレイヤーを理解した
  • LACE評価モデルの4軸を使ったスコアリングができる
  • 意図的ロックインの判断基準を理解した
  • ロックイン軽減のテクニックを理解した

次のステップへ

次は「マルチクラウド戦略パターン」を学びます。ロックインの評価結果を踏まえて、自社に適したマルチクラウド戦略のパターンを選定する方法を身につけましょう。

推定読了時間: 30分