Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Manage-less Infrastructure with Container and S...
Search
sakajunquality
April 25, 2018
Technology
1
1.1k
Manage-less Infrastructure with Container and Serverless
DevOpsDaysTokyo 2018
sakajunquality
April 25, 2018
Tweet
Share
More Decks by sakajunquality
See All by sakajunquality
DevFest Tokyo 2023: Google Cloudでチームで安全にデプロイをする
sakajunquality
10
1.8k
Cloud Spanner Monitoring 入門 / Cloud Spanner Monitoring Introduction
sakajunquality
1
1.3k
GKE Overview March 2021: Introducing Autopilot
sakajunquality
1
810
Introduction to Cloud Run 2021
sakajunquality
3
1.5k
Building Reliable Distributed Systems on GCP
sakajunquality
1
230
Istio 1.5 Updates
sakajunquality
4
1.9k
GCP 101: Getting Started through Cloud Run
sakajunquality
6
3.6k
Seeking Observability, Getting Started with Service Mesh
sakajunquality
0
140
Fastly Yamagoya Meetup: Leveraging Cloud Portability with Fastly
sakajunquality
0
16k
Other Decks in Technology
See All in Technology
ビジネスモデリング道場 目的と背景
masuda220
PRO
9
620
Raycast AI APIを使ってちょっと便利な拡張機能を作ってみた / created-a-handy-extension-using-the-raycast-ai-api
kawamataryo
0
110
生成 AI プロダクトを育てる技術 〜データ品質向上による継続的な価値創出の実践〜
icoxfog417
PRO
4
1.2k
運用しているアプリケーションのDBのリプレイスをやってみた
miura55
1
780
表現を育てる
kiyou77
1
220
デスクトップだけじゃないUbuntu
mtyshibata
0
250
目の前の仕事と向き合うことで成長できる - 仕事とスキルを広げる / Every little bit counts
soudai
26
7.4k
リーダブルテストコード 〜メンテナンスしやすい テストコードを作成する方法を考える〜 #DevSumi #DevSumiB / Readable test code
nihonbuson
11
7.4k
Culture Deck
optfit
0
430
The Future of SEO: The Impact of AI on Search
badams
0
220
分解して理解する Aspire
nenonaninu
1
360
滅・サービスクラス🔥 / Destruction Service Class
sinsoku
6
1.6k
Featured
See All Featured
Into the Great Unknown - MozCon
thekraken
35
1.6k
Code Reviewing Like a Champion
maltzj
521
39k
The Cult of Friendly URLs
andyhume
78
6.2k
The Language of Interfaces
destraynor
156
24k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.3k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
9
450
4 Signs Your Business is Dying
shpigford
182
22k
Measuring & Analyzing Core Web Vitals
bluesmoon
6
240
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.7k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
100
18k
Testing 201, or: Great Expectations
jmmastey
42
7.2k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.4k
Transcript
"Manage-less" Infrastructure with Container and Serverless DevOpsDays Tokyo 2018 @sakajunquality
About Me - SRE at eureka, Inc. - Web系インフラエンジニア -
ネットワークとか低レイヤーなとこ ろも好きです @sakajunquality
Agenda - Prologue - About“Manageless”Infrastructure - Things to consider -
Cases - Conclusion
Prologue
本題の前に・・・
この発表タイトルを見て
GAEじゃだめなの?
RDSつかってればいいんでしょ?
サーバーレス=Lambdaでしょ?
コンテナ?Docker?
Kubernetesの話?
サービスメッシュ?
Cloud Native?
ベンダーロック?
という疑問を持たれたかもしれません
だいたい正解です
重要なのはあくまでも 適切な組み合わせ
- Container - Serverless
サービスの提供形態で クラウドを整理してみる
簡単に言うとIaaS/PaaS/SaaS
出典: https://codezine.jp/article/detail/8051
さらに最近だとCaaS/FaaS/**asS
PaaS全般をあわせて サーバーレスとして扱います
Lambdaだけがサーバーレスじゃない
メリット
コンテナのメリット ※ 実行筐体に関わらず - コンテナ自体はImmutable Infrastructure - コンテナプールは、Resource Utilization
サーバーレスのメリット ※ サーバーレスの種類にかかわらず - 実体としてのリソースを管理しなくていい - あるいは管理が楽
“Manage-less” infrastructure
サービスとしてどこまで触れるか?
サービスとしてどこまで触れるか? = どこまで管理しなければならないか
極力自分で管理しなければならないものを 減らし、本来重要なところに集中する
本来取り組むべきは・・・ - アプリケーションのビジネスロジック - クリティカルな部分のインフラ - サービス全体での可用性 - etc.
要は、楽したい
楽をしつつも可用性を向上させたい
例えば、サーバー1台立てると
例えば、サーバー(VM)1台立てると - OS/ミドルウェアのセキュリティ・バウフィックスの定期的なパッチ - プロビジョニング方式や再現性 - 負荷分散、冗長化・・・ - アプリケーションのディプロイ -
各種ログの収集 - 法令、業界や会社の規制
めんどくさい
ちょっとしたサーバーも、 ビジネスレベルで運用するなら 考慮することが多すぎる
サーバーを立てたら負け
とまでは言わないが、 その後の運用を覚悟しなければならない
こんなことないですか? - gli◦cやopen◦s◦のような脆弱性パッチ当てに追われる - 昔に立てたWord◦ressを定期的にメンテナンスしなければならない - どこで動いてるかもわからないディプロイボットを定期的に面倒を見なければならな い - カジュアルに立てたRe◦ashが、クリティカルに使われる
- 気づいたらログが欠損していて復旧に追われる - etc.
管理するべき対象や物事が多すぎる
もちろん すべてインフラ面で解決しなきゃならないわ けではない
不要なものは捨てるのが一番
それでも管理するものはなくならない クラウドをつかって楽をする
※こんな場合には当てはまらないかも - インフラエンジニアが何十人もいる - ネットワーク/OS/各種ミドルウェア等のレイヤーごとに専任がいる - Netflixバリに完成度の高いプラットフォームを自社で有している
What you need to consider in cloud
クラウドで考慮すべきこと - ワークロード - クリティカル度合い - ベンダーロック
ワークロードから考えてみる
ワークロード - どういうワークロードなのか - イベントドリブン - Httpトラフィック - Heavy? Light?
- リソース - CPU/Memory/Disk... - 実行するために何が必要なのか - ミドルウェア
クリティカル度合い
クリティカル度合い - ビジネス上の重要度 - サービスでの利用のされ方 - 技術的要件 - 許容レイテンシ
ベンダーロック
ベンダーロック - 組織としてのベンダーとの付き合い方 - どこまで許容するのか - サポート形態 - そもそもベンダーを変えることがあるのか -
開発フローを阻害しないか - ローカル開発
Cases
実際の事例をいくつか
※弊社のユースケースにおいての技術選 定であって、特定のクラウドを勧めてるわけ ではありません
Case1. FaaS Deploy/Event Notification Function
Notification function on FaaS LambdaやCloud Functions - ワークロード - SNSやPubSubなどのイベントをフックに発火
- クリティカル度合い - ミリ秒単位で争うわけではない - ベンダーロック - 各関数はベンダースペシフィックに書く必要がある - ベンダーごとの言語の縛り
Notification function on FaaS LambdaやCloud Functions - ワークロード - 常時プロセスを起動させておく必要はない
- クリティカル度合い - 自前サーバーでイベントを受けても対して速さは変わらない - ベンダーロック - 関数自体大した量じゃない - 頻繁にディプロイするわけでもない
Case2. CaaS Deploy bot on GKE Redash on GKE
Deploybot on Kubernetes - ワークロード - Slack RTMの通信を常時行う - クリティカル度合い
- 死ぬとディプロイやロールバックができない - ベンダーロック - 特になし
Deploybot on Kubernetes - ワークロード - プロセスを起動し続ける必要がある - クリティカル度合い -
最低限オーケストレーション はちゃんと行いたい - ベンダーロック - ベンダーとしての選択肢が豊富かつ 載せ替えも容易 - GKE/EKS/Azure/Oracle/自前etc… - コンテナなのでローカル環境も構築しやすい
Redash on Kubernetes - ワークロード - それなりにヘビーなトラフィック - プロセスは常時起動 (Web/Worker)
- クリティカル度合い - オーケストレーションはちゃんとしたい - ベンダーロック - 省略
あるPaaSのすべての機能を使いこなす必要はない 例) Kubernetes ユースケースによっては、コンテナのオーケストレーションをやってくれさえすれば良い
Case3. PaaS Data pipeline Data warehouse
Data Pipeline via PubSub and Dataflow https://cloud.google.com/dataflow/?hl=ja
Data Pipeline via PubSub and Dataflow - ワークロード - 複数のアプリケーションサーバーから送られるログを
BigQueryに入れる - クリティカル度合い - 欠損時はビジネス上の意思決定、アプリケーションのアルゴリズムともに影響受ける - ベンダーロック - 完全にGCPロックイン
Data Pipeline via PubSub and Dataflow - ワークロード - とにかくログが多い
- クリティカル度合い - 欠損が許容されない - ベンダーロック - fluentdやkafkaを自前で運用するよりはパイプラインとしてよっぽど安定する - (GCPで障害になることもあるが ) - DataflowのApacheBeamは一応オープンソース
BigQuery as DataWarehouse and Analytics Engine - ワークロード - PBクラスのデータを保持
- TB/PBオーダーでの解析 - クリティカル度合い - 省略(DataPipelineと同じ) - ベンダーロック - 自前運用が事実上不可 - 完全にGCPロックイン - 載せ替えれないこともないが膨大なデータの移動とクエリの書き換え
Case3. IaaS Elasticsearch
それでもIaaS (VM)を使う場合もある
Elasticsearch
- サービス上クリティカルな部分(検索)で使用している - PaaS(Elasticsearch Service/ElasticCloud)もあるが - 書き込み頻度が高く耐えられない - レイテンシーが許容できない -
IaaS(EC2)で運用 - OSレベル、JVMレベルの事柄との付き合い Elasticsearch
- 以前EC2で運用していたMySQLはRDS Auroraに載せ替え - メンテナンス性、可用性を考慮し ちなみに
QED?
これですべて解決するか?
考えることがむしろ増えていないか - 確かに増えている - クラウドに知識やオペレーションの習得 - セキュアなコンテナの作り方 - etc. -
クラウドの知識は - サポートやハンズオンでもどうにかなる - コンテナの知識は - それなりに汎用的に使えるので覚える
エントロピー - 最初は覚えることが多い - 最初はオペレーションもなれない - 技術選定したうえで徐々に下げていくしかない
コストは?
コストは? - 当然考慮すべき - IaaSよりもPaaSを使うほうがコスト高にの傾向 - 人的コストや可用性との天秤
Conclusion
Conclusion - 本来すべきことに重きを置き、楽できるところは楽する - 何でも自分で用意する必要はない - 重要なことはサービスに応じて適切な組み合わせを取る
Thank you