[CTO Night & Day 2019] CTO のための一歩進んだコンテナ入門 #ctonight

© 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Morning Session:
CTO のための⼀歩進んだコンテナ⼊⾨

⾃⼰紹介
松⽥和樹 (Kazuki Matsuda)
アマゾンウェブサービスジャパン株式会社
スタートアップソリューションアーキテクト
• 前職 : 広告領域で BigData を扱うスタートアップ
• 現職 : スタートアップの技術⽀援をしつつ、⾏きたいところを物⾊
• #Container #BigData #DevOps #Elasticsearch #Aerospike
• 好きな AWS サービス : AWS Fargate, AWS Chalice

※ これからコンテナを始める⽅へ

AWS Startup ブログにて

今⽇話すこと
• 現場で Kubernetes を使いたいと⾔い出した時に考えること
• Amazon における DevOps とマイクロサービス
対象︓Seed 〜 Mid ステージなスタートアップ

• Docker 使いたい
• 機能が豊富
• デファクトスタンダード
• マイクロサービス化したい
• 使ってみたい
Kubernetes 使いたいです。

まず前提として、 ※ CTOs にわざわざ⾔うことでも無いですが
• Why を聞きすぎない。
• CTO が判断しすぎない。
• 聞き⽅によってはネガティブに受け取られたりも
• ⾃発的に使いたいといい出したのはポジティブですよね︖
CTO 視点で excuse する
（危なそうなときはストップをかける必要も）

Kubernetes について

Kubernetes (k8s) とは
• 複数のホスト間でコンテナ化されたアプリ
ケーションを管理する OSS
• デプロイ、メンテナンス、スケーリングと
いった基本的な機能を提供している
• Cloud Native Computing Foundation (CNCF)
によって管理、推進されている

Kubernetes の（特に）いいところ
• Custom Resource Definition (CDR)
• Kubernetes はプラットフォーム。
• 平たく⾔えば⾃分たちで AWS を作っているようなもの。
• その仕様が標準化されており、CDR で⾃社向けに拡張できる
ことがメリット。
• OSS の多さとコミュニティ
• 公開されている OSS で、⾃社のプロダクトを⼤きく前進させ
るものがあるのであれば使わない⼿はない。
• コミュニティ活動を通して、プレゼンスの向上に繋がることも

Kubernetes は機能が多い︖
⽴ち位置の違いから⽣まれるアプローチ差異の例
設定情報管理
Parameter Store
(AWS Systems Manager)
ConfigMap
秘密情報管理 AWS Secrets Manager Secrets
サービスディスカバリ AWS Cloud Map Service, etc.
バッチジョブ
Amazon CloudWatch Events,
AWS Step Functions
Jobs, CronJob
認証・認可 AWS IAM RBAC, Service Accounts, etc.

Kubernetes のスタートアップにとって微妙なところ
• Kubernetes はプラットフォーム
• 平たく⾔えば⾃分たちで AWS を作っているようなもの
• その管理運⽤をしなければならない。
• キャパシティ
• セキュリティ
• Pods が正常に配置されているか等の確認も
• あなた達が作りたいのはプラットフォームですか︖
• 本当にやりたいことは、価値のあるプロダクトを世の中に届ける
ことですよね︖

Kubernetes のスタートアップにとって微妙なところ
• 単に Docker を使いたいだけならオーバーキル気味︖
• とはいえ、デファクトスタンダードですよね︖
• What is a standard ? MySQL があれば PostgreSQL は要らないのか
• 社外へのプレゼンス、採⽤⾯
• では、マイクロサービスならどうか︖
• サービスメッシュは要るのか︖

マイクロサービスについて考える

Amazon における
マイクロサービスや DevOps の考え⽅

The Amazon Way
Photo credit: jurvetson via Visual Hunt / CC BY

Amazon.com in 2001

モノリシックな開発サイクル
releasetestbuild
開発者デリバリーパイプラインサービス

モノリシックなアーキテクチャの問題点
• 密結合
• メンテナンスと維持が難しい
• ソースコードが複雑に絡み合い、マージ⼀つでも⼀苦労
• ビルドやテストがとにかく時間がかかる
• デプロイがボトルネック
• デプロイが⼀⼤イベントとなる
• 1つのプロセスで提供される
• スケールが難しい

マイクロサービスアーキテクチャ
マイクロサービスアーキテクチャは1つのアプリケーションを小さなサービス
で、各々のプロセスで実行され、 HTTP の API のような Lightweight なメカ
ニズムで通信するようにする開発スタイルのアプローチです。
これらのサービスはビジネスケイパビリティから構築され、完全自動化され
た個別のデプロイができます。
サービスの集中型のマネジメントを最小化し、サービスは異なるプログラミ
ング言語で書かれ、異なるデータストレージが使われます。
-- James Lewis and Martin Fowler

Two Pizza Rule
• 全ての所有権
• 全ての説明責任

Two Pizza Teams の働き⽅
“サービスチーム”と呼ぶ
“プリミティブ”に所有し、構築
• プロダクトプランニング (ロードマップ)
• 開発
• 運⽤/カスタマーサポート
“You build it, you run it”
⼤きな組織の⼀部分を構成する
(Amazon.com, AWS, Prime, etc)

伝統的なシステムでは開発と運⽤の間に壁がある。
そんな壁はぶん投げてしまえ。
忘れてしまってもいい。Amazon では不要だ。
You build it, you run it
開発者も⽇々の運⽤に参加しなさい。
そうすればカスタマーのフィードバックが得られる。
これが、サービスの質を⾼めるのだ。
-- Werner Vogels in May 2006 / Amazon.com CTO

Microservices の開発ライフサイクル
開発者デリバリーパイプラインサービス
releasetestbuild
releasetestbuild
releasetestbuild
releasetestbuild
releasetestbuild
releasetestbuild

QA は誰が︖
The Two
Pizza
Team

オンコール
は誰が︖
The Two
Pizza
Team

Ops は
何をするのか
Not
Exist

Amazon における DevOps とは何か?
DevOps =
開発者顧客
releasetestbuild
plan monitor
デリバリのパイプライン
フィードバックループ
ソフトウェア開発のライフサイクル
無駄やボトルネックを取り除くことで、
ライフサイクルを効率化し、⾼速化すること

Culture
文化
Practices
習慣
Tools
ツール
3 Keys of successful DevOps

Culture
• 壁を取り払う
• Dev と Ops
• DevOps チーム間
• 中間プロセス
• 所有権と説明責任をチームに
• 個⼈に対する責任は⼩さく
• ⼀般的に⼤きなチームは、⼩さなチームより遅い
• 常に改善をして⾼みを⽬指し、How には柔軟さを残す

Amazon Our Leadership Principles (OLP)
• Customer Obsession
• Ownership
• Invent and Simplify
• Are Right, A Lot
• Learn and Be Curious
• Hire and Develop The Best
• Insist on the Highest
Standards
• Think Big
• Bias for Action
• Frugality
• Earn Trust
• Dive Deep
• Have Backbone; Disagree and
Commit
• Deliver Results
https://www.amazon.jobs/jp/principles

OLP を3つピックアップ
Customer Obsession
リーダーはカスタマーを起点に考え⾏動します。カスタマーから信頼を獲得し、
維持していくために全⼒を尽くします。リーダーは競合に注意を払いますが、
何よりもカスタマーを中⼼に考えることにこだわります。
Ownership
リーダーにはオーナーシップが必要です。リーダーは⻑期的な視野で考え、短
期的な結果のために、⻑期的な価値を犠牲にしません。リーダーは⾃分のチー
ムだけでなく、会社全体のために⾏動します。リーダーは「それは私の仕事で
はありません」とは決して⼝にしません。
Bias for Action
ビジネスではスピードが重要です。多くの意思決定や⾏動はやり直すこともで
きるため、⼤がかりな分析や検討を必要としません。計算されたリスクをとる
ことも⼤切です。

Conway の法則
いかなる組織のシステム設計においても、⽣成される設計は、
組織のコミュニケーション構造のコピーとなる。
-- Melvin Conway, 1967

まとめ

まとめ
• ちゃんと考えて選定する（切実）
• 技術を使うこと⾃体が⽬的になっていても問題はない
（それ⾃体を⾃覚していれば）
• 共通基盤的なものが、逆にマイクロサービスを阻害しないか
• 良い技術やツールであっても、⾃社の⽬的にマッチしないこ
とは多くある
• Amazon はマイクロサービスを採⽤している企業の⼀つ
• Amazon において、マイクロサービスは単なるシステムの構
造ではなく、働き⽅や会社の構造そのもの。
• マイクロサービスはツールや技術で実現するものでは無い

Q&A

Thank you!

[CTO Night & Day 2019] CTO のための一歩進んだコンテナ入門 #ctonight

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie [CTO Night & Day 2019] CTO のための一歩進んだコンテナ入門 #ctonight

Ähnlich wie [CTO Night & Day 2019] CTO のための一歩進んだコンテナ入門 #ctonight (20)

Mehr von Amazon Web Services Japan

Mehr von Amazon Web Services Japan (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (10)

[CTO Night & Day 2019] CTO のための一歩進んだコンテナ入門 #ctonight