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
150
Fastly Yamagoya Meetup: Leveraging Cloud Portability with Fastly
sakajunquality
0
16k
Other Decks in Technology
See All in Technology
「正しく」失敗できる チームの作り方 〜リアルな事例から紐解く失敗を恐れない組織とは〜 / A team that can fail correctly
i35_267
1
540
Oracle Cloud Infrastructure:2025年2月度サービス・アップデート
oracle4engineer
PRO
1
340
OpenID Connect for Identity Assurance の概要と翻訳版のご紹介 / 20250219-BizDay17-OIDC4IDA-Intro
oidfj
0
400
TAMとre:Capセキュリティ編 〜拡張脅威検出デモを添えて〜
fujiihda
2
360
OSS構成管理ツールCMDBuildを使ったAWSリソース管理の自動化
satorufunai
0
360
(機械学習システムでも) SLO から始める信頼性構築 - ゆる SRE#9 2025/02/21
daigo0927
0
200
Apache Iceberg Case Study in LY Corporation
lycorptech_jp
PRO
0
140
利用終了したドメイン名の最強終活〜観測環境を育てて、分析・供養している件〜 / The Ultimate End-of-Life Preparation for Discontinued Domain Names
nttcom
2
320
Active Directory攻防
cryptopeg
PRO
7
4.5k
Iceberg Meetup Japan #1 : Iceberg and Databricks
databricksjapan
0
180
一度 Expo の採用を断念したけど、 再度 Expo の導入を検討している話
ichiki1023
1
240
php-conference-nagoya-2025
fuwasegu
0
110
Featured
See All Featured
Bootstrapping a Software Product
garrettdimon
PRO
306
110k
The Invisible Side of Design
smashingmag
299
50k
The Cult of Friendly URLs
andyhume
78
6.2k
Speed Design
sergeychernyshev
27
800
StorybookのUI Testing Handbookを読んだ
zakiyama
28
5.5k
Making the Leap to Tech Lead
cromwellryan
133
9.1k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.3k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.7k
Code Review Best Practice
trishagee
67
18k
Designing Experiences People Love
moore
140
23k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
How to Think Like a Performance Engineer
csswizardry
22
1.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