T O K Y O - pages.awscloud.compages.awscloud.com/rs/112-TZM-766/images/F-3.pdfる。Cassandra...

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

T O K Y O2

01

9.1

0.0

3-

04


T O K Y O

20

19

.10

.03

-0

4

開発におけるロックインのリスク評価と考え方

Fumihiko HataSolutions ArchitectAmazon Web Services Japan

F - 3


Who am I


Agenda

1. “lock-in” とは何か

2. Switching costsで考えるリスク評価

3. ロックインのリスクを低減しつつかつ開発速度も向上させる


What is lock-in?

あるベンダーの製品 Aを採用した。時間が経ち、その製品 Aをやめて他社の別製品 Bに変更したくなった。しかしそれができない、あるいは多大な労力を要する。

Why?

• その製品 A特有の機能 Xを手放すことができない

• その製品 Aの抜きん出た性能を手放すことができない

• その製品 Aのライセンスや契約に利用期間を縛られている

• その製品 Aのボリューム・ディスカウントが大きく、部分的な変更によるコスト影響が大きすぎる

• etc.


What is lock-in?

• ベンダーロックイン：• ロックインと言うときはこれを指すことが多い。前ページで説明したような状況。

� 特定のベンダーが提供するプラットフォームなんてリスク大きすぎる？→オンプレミス？あるいはマルチクラウドなら解決？

� ベンダーフリーな OSS製品だけを使う？→その OSSがメンテナンスされなくなったら？


What is lock-in?


• プロダクトロックイン：• ベンダーロックインの状況において大抵はプロダクトロックインにもなっている。

• ただし、ベンダーがいないプロダクト、例えば OSSでもプロダクト・ロックインは起きうる。Cassandraを使い倒して何年も経ってデータ量も多い状態から HBaseに移行しようとすると、移行はどれくらいの労力でしょうか。この場合、ベンダーはいません。しかし、ベンダーロックインと同様に開発コミュニティにロックインしているという捉え方も。


What is lock-in?




• プラットフォームロックイン：• 単一の製品ではなく、プラットフォームの製品群やそのサービス全体に対するロックイン


What is lock-in?




• プラットフォームロックイン：• 単一の製品ではなく、プラットフォームの製品群やそのサービス全体に対するロックイン

• アーキテクチャロックイン：• サーバーレスアーキテクチャをコンテナベースのアーキテクチャに変えるとしたら？

• マイクロサービスとモノリスではどちらがアーキテクチャ変更しやすいでしょうか？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

https://martinfowler.com/articles/oss-lockin.html


What is lock-in?

例えば、

• Amazon DynamoDBはロックインのリスクがありますか？

• MySQL on EC2 なら安心ですか？→「MySQLという OSSプロダクトへのロックイン」という考慮は

杞憂でしょうか。• EC2だから気しないでいられた物理サーバや OSのパッチやアップデートは、オンプレミスに移行したら運用が変わりませんか？その移行コストは無視できるほどに小さい？

• それでも、 Amazon Aurora MySQLや RDS MySQLよりは移行時のコストが低そうでしょうか。


What is lock-in?

• ロックインする / しない、ロックインしている / していない

→どちらかの状態にきれいに分けてリスクが存在するわけではない間にはグラデーションがある

存在するのは、ベンダーやツールやサービスなどを乗り換えようとする際に乗り換えにかかるコスト→ Switching costs

Switching costs が現実的な値を超えそうなときや著しく大きくなりそうなとき→「ロックインする（している）」と表現されがち


Switching costs

• Lock-in:Lock-in する / Lock-inしない

• Switching costs:Switching costsは量を評価できる概念でありバイナリ（２値）ではない。• どのくらいの費用が？

• どのくらいの時間が？

• どのくらいのエンジニアリソースが？


“「ロックイン」という用語は誤解を招きます。私たちはただ 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』著者

https://aws.amazon.com/blogs/enterprise-strategy/switching-costs-and-lock-in/


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-newmanVideo: https://www.slideshare.net/spnewman/its-a-trap-176000461

https://skillsmatter.com/skillscasts/12951-keynote-sam-newman

https://www.slideshare.net/spnewman/its-a-trap-176000461



• 私達のビジネスを全て学んで、私達の仕事を奪う気だろ！

• そのサービスの提供が突然終わるかもしれない

• 価格を不当に釣り上げてくるかも！






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 は下がるのか？しかし、０になることはない


2. “価格を不当に釣り上げてくるかも！”

• これも可能性の話をするならもちろん、あるかもしれない

• これがどれほどありうるかのパーセンテージの試算は各自が

しかし判断材料はあり

あとはさっきと同様に

AWS のクラウドが選ばれる 10 の理由 | AWShttps://aws.amazon.com/jp/aws-ten-reasons/

https://aws.amazon.com/jp/aws-ten-reasons/



クラウドのサービスを今日から使う？今その利益を享受して、あとで代償を支払う

クラウドのサービスを今は使わない？将来の潜在的な乗り換えコストを避けるかわりに、今すぐコストを支払う






Gregor Hohpe『Don’t get locked up into avoiding lock-in』(9th Sep. 2019)





• Liability: 負債

• 横軸：ロックインを軽減するための事前投資（初期投資）

• 縦軸：総コスト←青線か赤線かによって含まれる対象が異なる

負債（青線）＝ switching cost とそのswitch が起きる可能性の積で定義

負債＋事前投資（赤線）





ロックインを避ける（ switching costを下げる）ために、事前投資すればするほど、当然 switch におけるコスト（＝負債：青線）も下がっている

一方で、その事前投資自体を含めて総コスト（赤線）を評価すると「事前投資すればするほど良い」とはならずにどこかで「やり過ぎ」になっている

これは、そもそも switch はそうそう起きない。間違った方向や不要な方向に投資する可能性は大きい




Switching costs を低下させるだけでなく開発そのものにも利益を生むような投資はないのか


Switching costs にも開発速度の向上にも効く効率の良い投資先

1. 技術的負債と向き合う

2. CI/CD パイプライン

3. Infrastructure as Code

4. 疎結合なアーキテクチャ


１．技術的負債と向き合う

利用するサービスやソフトウェアを変更しようとした際に最もハードルとなるのが、現在採用しているサービスやソフトウェア自体による制約よりもそれらを利用している側のコードの技術的負債であることは多々ある

• 時間がないためにチェックインされたアドホックな修正

• 忘れ去られる多数のモンキーパッチ

• １人しか把握していないコード、もしくはその人もチームを去った

• 単体テストがない、負荷テストは 1st launch 以来やってない、

• etc..


１．技術的負債と向き合う

• Switching costsが負債なら、技術的負債はより包括的な負債

• Switch だけでなく、日々の開発にも大きな影響を与える変数

• 単純に技術的負債に向き合い開発の velocityを上げることがswitching costsを含む多くの課題を包括的に解決していく

• Scrum / Agile

• テスティング・スキル

• リファクタリング

• アーキテクティング…

技術的負債と向き合う方法論は様々

Chaos Test

Penetration Test

Performance Test

UI Test

Integration Test

Unit Test


２．CI/CDの整備

• 継続的インテグレーション

• 継続的デリバリ（デプロイメント）

サービスにしろミドルウェアにしろ、移行に際してコードの修正や対応が不要であることはまずない

むしろコード側が柔軟に対応できる状態であれば switch の選択肢は拡がる


CI/CDパイプライン

Source Build Test Production

継続的インテグレーション

継続的デプロイメント

継続的デリバリー


デプロイメント・パイプラインを実現するAWSサービス

ソースコードのバージョン管理

ビルド自動化

ワークフロー管理

デプロイ自動化

AWS CodeBuild

AWS CodeCommit

AWS CodeDeploy

AWS CodePipeline

AWS CodeStar

AWS CloudFormation AWS Elastic Beanstalk


AWS Code Services✤ セキュア、スケーラブルな Git 互換のリポジトリサービス✤ スタンダードな Git Tool からアクセス可能✤ Pushなどのイベントをトリガーに SNS/Lambda を呼び出し可能

✤ スケーラビリティに優れたビルドサービス✤ ソースのコンパイル、テスト、パッケージ生成をサポート✤ Docker イメージのビルドも可能

✤ S3 または GitHub 上のコードをあらゆるインスタンスにデプロイ✤ デプロイを安全に実行するための機能を提供✤ エージェント方式によるPull型で、オンプレミスへのデプロイもサポート

✤ リリースプロセスのモデル化と見える化を実現✤ カスタムアクションによる柔軟なパイプライン作成が可能✤ 様々な AWS サービスや 3rd パーティ製品との統合をサポート

AWS CodeBuild

AWS CodeCommit

AWS CodeDeploy

AWS CodePipeline


３．Infrastructure as Code

• インフラストラクチャ全体をプログラミング言語や JSON, YAMLなどでモデル化

• 繰り返し可能な方法でリソースをプロビジョニング及びデストロイ

AWS CloudFormationAWS CloudFormation


手動操作（マネジメントコンソール）

� 始めるのは簡単

� 繰り返し可能ではない

� エラーが起きやすい

� 時間がかかる

High level

Low levelManual


スクリプト (SDK, CLI)

� APIコールが失敗したら何が起こる？

� どうやってアップデートする？

� リソースが準備完了なのはどうやって知る？

� どうやってロールバックする？

Scripted

Manual

High level

Low level


プロビジョニングツール (CloudFormationなど)

AWS CloudFormation テンプレート

(JSON/YAML)

HashiCorp Configuration Language (HCL)

あるべき状態の定義

Declarative

Scripted

Manual

High level

Low level

� 自動化が容易

� 再生成可能

� ツール固有の記述方式

� 抽象化なし、詳細な記述


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テンプレート

の生成


４．疎結合なアーキテクチャ

疎結合なアーキテクチャは、アーキテクチャの変更コストが低いサービスやミドルウェアを変更する際にアーキテクチャに影響が及ぶことは少なくない

• メッセージ・キューによる、非同期化

• コンテナ化によるホスト OS環境との分離

• Service Discovery (Client side service discovery)

• LB (Server side service discovery)

• サービス・メッシュ

• Microservices?

Amazon MQ

Amazon Simple Queue

Service

Amazon Elastic Container

ServiceAmazon Elastic

Kubernetes Service

AWS App Mesh

AWS Cloud Map

Elastic Load Balancing


Switching costs にも開発速度の向上にも効く効率の良い投資先

1. 技術的負債と向き合う

2. CI/CD パイプライン

3. Infrastructure as Code

4. 疎結合なアーキテクチャ


開発にまつわる様々な変更コストを下げる

1. 技術的負債と向き合う→コード、インフラ、アーキテクチャ、そして組織の変更コスト下げる

2. CI/CD パイプライン→ソフトウェア（コード）の変更コストを下げる

3. Infrastructure as Code→インフラストラクチャの変更コストを下げる

4. 疎結合なアーキテクチャ→アーキテクチャの変更コストを下げる


まとめ✅ lock-in の形態と程度は多様

✅ lock-inする/しないの２値で雑に扱わない、思考停止しない→ lock-in のリスクは switching costsとして定量的に捉える

✅（switchにかかる費用 ✕ switchの発生確率）ー switchしなかった場合に享受できる継続的な利益

✅開発上の、そしてビジネス上のリスクは lock-in 以外にも多数存在リスクヘッジの ROIを意識

✅技術的負債と向き合い、普遍的な開発力向上に投資を。多数のツールを飼い慣らすことに投資するのではなく、素晴らしいツールを使い倒すことにリソースを投下


アンケートご協力のお願いお手持ちの受講票のアンケート用QRコードから

アンケートにお答えいただくと、記念品を差し上げております。

※イメージです

プレゼントの引き換えは、神田明神の会場出口付近（屋外）までお越しください

IT情報安全守護

2019 年 10 月 1 日〜11 月 5 日開催amzn.to/AWSInnovateJP

申し込み受付中

AWS 最新アップデート / コンテナ / AIML / AWS アンチパターン /

認定試験対策講座など60セッション

オンラインで参加できるカンファレンス、全 60 セッション

10/9, 10/15 ライブ配信AWS エキスパートへの

Q&A

修了証明書の発行業務時間に視聴

2019 年 10 月 1 日〜11 月 5 日開催amzn.to/AWSInnovateJP

Application Development

Container

Serverless

オンラインで参加できるカンファレンス、全 60 セッション

おすすめセッション

Thank you!


T O K Y O - pages.awscloud.compages.awscloud.com/rs/112-TZM-766/images/F-3.pdfる。Cassandra...

Documents

Transcript of T O K Y O - pages.awscloud.compages.awscloud.com/rs/112-TZM-766/images/F-3.pdfる。Cassandra...