© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. T O K Y O 2 0 1 9 . 1 0 . 0 3 - 0 4 開発におけるロックインの リスク評価と考え方 Fumihiko Hata Solutions Architect Amazon Web Services Japan F - 3

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Who am I

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Agenda 1. “lock-in” とは何か 2. Switching costs で考えるリスク評価 3. ロックインのリスクを低減しつつかつ開発速度も向上させる

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. What is lock-in? あるベンダーの製品 A を採用した。 時間が経ち、その製品 A をやめて他社の別製品 B に変更したくなった。 しかしそれができない、あるいは多大な労力を要する。 Why? • その製品 A 特有の機能 X を手放すことができない • その製品 A の抜きん出た性能を手放すことができない • その製品 A のライセンスや契約に利用期間を縛られている • その製品 A のボリューム・ディスカウントが大きく、 部分的な変更によるコスト影響が大きすぎる • etc.

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. What is lock-in? あるベンダーの製品 A を採用した。 時間が経ち、その製品 A をやめて他社の別製品 B に変更したくなった。 しかしそれができない、あるいは多大な労力を要する。 Why? • その製品 A 特有の機能 X を手放すことができない • その製品 A の抜きん出た性能を手放すことができない • その製品 A のライセンスや契約に利用期間を縛られている • その製品 A のボリューム・ディスカウントが大きく、 部分的な変更によるコスト影響が大きすぎる • etc.

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. What is lock-in? • ベンダーロックイン： • ロックインと言うときはこれを指すことが多い。前ページで説明したような状況。 特定のベンダーが提供するプラットフォームなんてリスク大きすぎる？ → オンプレミス？あるいはマルチクラウドなら解決？ ベンダーフリーな OSS 製品だけを使う？ → その OSS がメンテナンスされなくなったら？

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. What is lock-in? • ベンダーロックイン： • ロックインと言うときはこれを指すことが多い。前ページで説明したような状況。 • プロダクトロックイン： • ベンダーロックインの状況において大抵はプロダクトロックインにもなっている。 • ただし、ベンダーがいないプロダクト、例えば OSS でもプロダクト・ロックインは起きう る。Cassandra を使い倒して何年も経ってデータ量も多い状態から HBase に移行しようとする と、移行はどれくらいの労力でしょうか。この場合、ベンダーはいません。しかし、ベンダー ロックインと同様に開発コミュニティにロックインしているという捉え方も。

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. What is lock-in? • ベンダーロックイン： • ロックインと言うときはこれを指すことが多い。前ページで説明したような状況。 • プロダクトロックイン： • ベンダーロックインの状況において大抵はプロダクトロックインにもなっている。 • ただし、ベンダーがいないプロダクト、例えば OSS でもプロダクト・ロックインは起きうる。 Cassandra を使い倒して何年も経ってデータ量も多い状態から HBase に移行しようとすると、 移行はどれくらいの労力でしょうか。この場合、ベンダーはいません。しかし、ベンダーロッ クインと同様に開発コミュニティにロックインしているという捉え方も。 • プラットフォームロックイン： • 単一の製品ではなく、プラットフォームの製品群やそのサービス全体に対するロックイン

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. What is lock-in? • ベンダーロックイン： • ロックインと言うときはこれを指すことが多い。前ページで説明したような状況。 • プロダクトロックイン： • ベンダーロックインの状況において大抵はプロダクトロックインにもなっている。 • ただし、ベンダーがいないプロダクト、例えば OSS でもプロダクト・ロックインは起きうる。 Cassandra を使い倒して何年も経ってデータ量も多い状態から HBase に移行しようとすると、 移行はどれくらいの労力でしょうか。この場合、ベンダーはいません。しかし、ベンダーロッ クインと同様に開発コミュニティにロックインしているという捉え方も。 • プラットフォームロックイン： • 単一の製品ではなく、プラットフォームの製品群やそのサービス全体に対するロックイン • アーキテクチャロックイン： • サーバーレスアーキテクチャをコンテナベースのアーキテクチャに変えるとしたら？ • マイクロサービスとモノリスではどちらがアーキテクチャ変更しやすいでしょうか？ Gregor Hohpe の『Don‘t get locked up into avoiding lock-in』の記事では、これ以外に Skills Lock-in, Mental Lock-in, Version Lock-in など挙げより詳細な考察をしています。 https://martinfowler.com/articles/oss-lockin.html

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. What is lock-in? 例えば、 • Amazon DynamoDB はロックインのリスクがありますか？ • MySQL on EC2 なら安心ですか？ → 「MySQL という OSS プロダクトへのロックイン」という考慮は 杞憂でしょうか。 • EC2 だから気しないでいられた物理サーバや OS のパッチやアップデートは、オンプレミスに 移行したら運用が変わりませんか？その移行コストは無視できるほどに小さい？ • それでも、 Amazon Aurora MySQL や RDS MySQL よりは移行時のコストが低そうでしょう か。

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. What is lock-in? • ロックイン する / しない、 ロックイン している / していない → どちらかの状態にきれいに分けて リスク が存在するわけではない 間にはグラデーションがある 存在するのは、ベンダーやツールやサービスなどを乗り換えようとする際 に乗り換えにかかるコスト → Switching costs Switching costs が現実的な値を超えそうなときや著しく大きくなりそうな とき → 「ロックインする（している）」と表現されがち

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Switching costs • Lock-in: Lock-in する / Lock-in しない • Switching costs: Switching costs は量を評価できる概念であり バイナリ（２値）ではない。 • どのくらいの費用が？ • どのくらいの時間が？ • どのくらいのエンジニアリソースが？

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. “「ロックイン」という用語は誤解を招きます。私たちは ただ switching costs の話をしています。 switching costs は IT の歴史を通じて常に存在していました。プラット フォームまたはベンダーにコミットすると、その瞬間に、 後から変更する場合の switching costs が生まれます。 Java を選択してから Node.js に移行すればコストがかか ります。（中略）そこには単に switching costs があるだ けです。状況によってそのコストは大きくも小さくもな ります。” Mark Schwartz, Enterprise Strategist AWS 『Switching Costs and Lock-In』 元 US Citizenship and Immigration Service の CIO 『a Seat at the Table』,『THE ART OF BUSINESS VALUE』著者

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Sam Newman @CloudNative London 2019 Keynote 『 It’s a Trap! Vendor Lock-in and the Cloud 』 Sam Newman は 元 ThoughtWorks の Technical Consultant 。現在は 独立している。 Cloud, CD,そして Microservices が得意分野で、数多 くの企業でシステムのアーキテク ティングを経験。また、 『 Building Microservices 』の著者 Sam Newman 『 It’s a Trap! Vendor Lock-in and the Cloud 』 @CloudNative London 2019 (25th Sep) Slide: https://skillsmatter.com/skillscasts/12951-keynote-sam-newman Video: https://www.slideshare.net/spnewman/its-a-trap-176000461

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Sam Newman @CloudNative London 2019 Keynote 『 It’s a Trap! Vendor Lock-in and the Cloud 』 • 私達のビジネスを全て学んで、 私達の仕事を奪う気だろ！ • そのサービスの提供が 突然終わるかもしれない • 価格を不当に釣り上げて くるかも！ Sam Newman 『 It’s a Trap! Vendor Lock-in and the Cloud 』 @CloudNative London 2019 (25th Sep) Slide: https://skillsmatter.com/skillscasts/12951-keynote-sam-newman Video: https://www.slideshare.net/spnewman/its-a-trap-176000461

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Sam Newman @CloudNative London 2019 Keynote 『 It’s a Trap! Vendor Lock-in and the Cloud 』 • 私達のビジネスを全て学んで、 私達の仕事を奪う気だろ！ • そのサービスの提供が 突然終わるかもしれない • 価格を不当に釣り上げて くるかも！ Sam Newman 『 It’s a Trap! Vendor Lock-in and the Cloud 』 @CloudNative London 2019 (25th Sep) Slide: https://skillsmatter.com/skillscasts/12951-keynote-sam-newman Video: https://www.slideshare.net/spnewman/its-a-trap-176000461

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. 1. “そのサービスの提供が突然終わるかもしれない” • これを True / False の２値で評価するなら常に True 「〜かもしれない」可能性が０になることはない → そして「 lock-in するかもしれない」も True • switching costs で考えるなら、例えば Amazon ECS が・・・ • サービスを終了する可能性/確率はどの程度なのか？ • どの程度の期間における話なのか？ • そのゲームやサービスが5年続く可能性はどれくらい？その社内システムの耐用年数は？ • switch する可能性はどの程度なのか？ • Amazon ECS を使った場合に得られる数多くの利益（AutoScaling, SpotInstance, Fargate, Other services integrations, etc..）はいかほどか？ • 競合がそれら利益を享受して鋭意開発を進めていたら？ → 裏返せば、それは開発力について異なるリスク • Amazon EKS を使えば将来の switching cost は下がるのか？しかし、０になることはない

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. 2. “価格を不当に釣り上げてくるかも！” • これも可能性の話をするならもちろん、あるかもしれない • これがどれほどありうるかの パーセンテージの試算は各自が しかし判断材料はあり あとはさっきと同様に AWS の クラウドが選ばれる 10 の理由 | AWS https://aws.amazon.com/jp/aws-ten-reasons/

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Sam Newman @CloudNative London 2019 Keynote 『 It’s a Trap! Vendor Lock-in and the Cloud 』 クラウドのサービスを今日から使う？ 今その利益を享受して、あとで代償を 支払う クラウドのサービスを今は使わない？ 将来の潜在的な乗り換えコストを避け るかわりに、今すぐコストを支払う Sam Newman 『 It’s a Trap! Vendor Lock-in and the Cloud 』 @CloudNative London 2019 (25th Sep) Slide: https://skillsmatter.com/skillscasts/12951-keynote-sam-newman Video: https://www.slideshare.net/spnewman/its-a-trap-176000461

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Gregor Hohpe 『Don’t get locked up into avoiding lock-in』(9th Sep. 2019) https://martinfowler.com/articles/oss-lockin.html

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Gregor Hohpe 『Don’t get locked up into avoiding lock-in』(9th Sep. 2019) • Liability: 負債 • 横軸：ロックインを軽減するための 事前投資（初期投資） • 縦軸：総コスト ← 青線か赤線かに よって含まれる対象が異なる 負債（青線）＝ switching cost とその switch が起きる可能性の積で定義 負債＋事前投資（赤線） https://martinfowler.com/articles/oss-lockin.html

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Gregor Hohpe 『Don’t get locked up into avoiding lock-in』(9th Sep. 2019) ロックインを避ける（ switching cost を下げる）ために、事前投資すればす るほど、当然 switch におけるコスト （＝負債：青線）も下がっている 一方で、その事前投資自体を含めて総 コスト（赤線）を評価すると「事前投 資すればするほど良い」とはならずに どこかで「やり過ぎ」になっている これは、そもそも switch はそうそう 起きない。間違った方向や不要な方向 に投資する可能性は大きい https://martinfowler.com/articles/oss-lockin.html

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Switching costs を低下させるだけでなく 開発そのものにも利益を生むような投資はないのか

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Switching costs にも開発速度の向上にも効く 効率の良い投資先 1. 技術的負債と向き合う 2. CI/CD パイプライン 3. Infrastructure as Code 4. 疎結合なアーキテクチャ

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. １．技術的負債と向き合う 利用するサービスやソフトウェアを変更しようとした際に 最もハードルとなるのが、 現在採用しているサービスやソフトウェア自体による制約よりも それらを利用している側のコードの技術的負債であることは多々ある • 時間がないためにチェックインされたアドホックな修正 • 忘れ去られる多数のモンキーパッチ • １人しか把握していないコード、もしくはその人もチームを去った • 単体テストがない、負荷テストは 1st launch 以来やってない、 • etc..

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. １．技術的負債と向き合う • Switching costs が負債なら、技術的負債はより包括的な負債 • Switch だけでなく、日々の開発にも大きな影響を与える変数 • 単純に技術的負債に向き合い開発の velocity を上げることが switching costs を含む多くの課題を包括的に解決していく • Scrum / Agile • テスティング・スキル • リファクタリング • アーキテクティング… 技術的負債と向き合う方法論は様々 Chaos Test Penetration Test Performance Test UI Test Integration Test Unit Test

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. ２．CI/CD の整備 • 継続的インテグレーション • 継続的デリバリ（デプロイメント） サービスにしろミドルウェアにしろ、移行に際してコードの修正や対応が 不要であることはまずない むしろコード側が柔軟に対応できる状態であれば switch の選択肢は拡がる

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. CI/CD パイプライン Source Build Test Production 継続的インテグレーション 継続的デプロイメント 継続的デリバリー

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. デプロイメント・パイプラインを実現するAWSサービス ソースコードの バージョン管理 ビルド⾃動化 ワークフロー管理 デプロイ⾃動化 AWS CodeBuild AWS CodeCommit AWS CodeDeploy AWS CodePipeline AWS CodeStar AWS CloudFormation AWS Elastic Beanstalk

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. AWS Code Services ✤ セキュア、スケーラブルな Git 互換のリポジトリサービス ✤ スタンダードな Git Tool からアクセス可能 ✤ Pushなどのイベントをトリガーに SNS/Lambda を呼び出し可能 ✤ スケーラビリティに優れたビルドサービス ✤ ソースのコンパイル、テスト、パッケージ⽣成をサポート ✤ Docker イメージのビルドも可能 ✤ S3 または GitHub 上のコードをあらゆるインスタンスにデプロイ ✤ デプロイを安全に実⾏するための機能を提供 ✤ エージェント⽅式によるPull型で、オンプレミスへのデプロイもサポート ✤ リリースプロセスのモデル化と⾒える化を実現 ✤ カスタムアクションによる柔軟なパイプライン作成が可能 ✤ 様々な AWS サービスや 3rd パーティ製品との統合をサポート AWS CodeBuild AWS CodeCommit AWS CodeDeploy AWS CodePipeline

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. ３．Infrastructure as Code • インフラストラクチャ全体をプログラミング言語や JSON, YAML などで モデル化 • 繰り返し可能な方法でリソースをプロビジョニング及びデストロイ AWS CloudFormation AWS CloudFormation

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. ⼿動操作（マネジメントコンソール） 始めるのは簡単 繰り返し可能ではない エラーが起きやすい 時間がかかる High level Low level Manual

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. スクリプト (SDK, CLI) APIコールが失敗したら何が起こる︖ どうやってアップデートする︖ リソースが準備完了なのはどうやって知る︖ どうやってロールバックする︖ Scripted Manual High level Low level

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. プロビジョニング ツール (CloudFormationなど) AWS CloudFormation テンプレート (JSON/YAML) HashiCorp Configuration Language (HCL) あるべき状態の定義 Declarative Scripted Manual High level Low level ⾃動化が容易 再⽣成可能 ツール固有の記述⽅式 抽象化なし、詳細な記述

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. AWS CloudFormation template AWS CDK Application Stack(s) Construct Construct AWS CDK (コンポーネント化) Componentized DOMs Declarative Scripted Manual High level Low level AWS CloudFormation Template コードであるべき状態を定義 CFnで デプロイ CFnテンプレート の⽣成

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. ４．疎結合なアーキテクチャ 疎結合なアーキテクチャは、アーキテクチャの変更コストが低い サービスやミドルウェアを変更する際にアーキテクチャに影響が及ぶこと は少なくない • メッセージ・キューによる、非同期化 • コンテナ化によるホスト OS 環境との分離 • Service Discovery (Client side service discovery) • LB (Server side service discovery) • サービス・メッシュ • Microservices? Amazon MQ Amazon Simple Queue Service Amazon Elastic Container Service Amazon Elastic Kubernetes Service AWS App Mesh AWS Cloud Map Elastic Load Balancing

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. Switching costs にも開発速度の向上にも効く 効率の良い投資先 1. 技術的負債と向き合う 2. CI/CD パイプライン 3. Infrastructure as Code 4. 疎結合なアーキテクチャ

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. 開発にまつわる様々な変更コストを下げる 1. 技術的負債と向き合う → コード、インフラ、アーキテクチャ、そして組織の変更コスト下げる 2. CI/CD パイプライン → ソフトウェア（コード）の変更コストを下げる 3. Infrastructure as Code → インフラストラクチャの変更コストを下げる 4. 疎結合なアーキテクチャ → アーキテクチャの変更コストを下げる

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved. まとめ lock-in の形態と程度は多様 lock-in する/しない の２値で雑に扱わない、思考停止しない → lock-in のリスクは switching costs として定量的に捉える （switch にかかる費用 ✕ switch の発生確率） ー switch しなかった場 合に享受できる継続的な利益 開発上の、そしてビジネス上のリスクは lock-in 以外にも多数存在 リスクヘッジの ROI を意識 技術的負債と向き合い、普遍的な開発力向上に投資を。 多数のツールを飼い慣らすことに投資するのではなく、 素晴らしいツールを使い倒すことにリソースを投下