Tweet
Tweet

Slide 1

Slide 1 text

"Manage-less" Infrastructure with Container and Serverless DevOpsDays Tokyo 2018 @sakajunquality

Slide 2

Slide 2 text

About Me - SRE at eureka, Inc. - Web系インフラエンジニア - ネットワークとか低レイヤーなとこ ろも好きです @sakajunquality

Slide 3

Slide 3 text

Agenda - Prologue - About“Manageless”Infrastructure - Things to consider - Cases - Conclusion

Slide 4

Slide 4 text

Prologue

Slide 5

Slide 5 text

本題の前に・・・

Slide 6

Slide 6 text

この発表タイトルを見て

Slide 7

Slide 7 text

GAEじゃだめなの？

Slide 8

Slide 8 text

RDSつかってればいいんでしょ？

Slide 9

Slide 9 text

サーバーレス＝Lambdaでしょ？

Slide 10

Slide 10 text

コンテナ?Docker?

Slide 11

Slide 11 text

Kubernetesの話？

Slide 12

Slide 12 text

サービスメッシュ？

Slide 13

Slide 13 text

Cloud Native？

Slide 14

Slide 14 text

ベンダーロック?

Slide 15

Slide 15 text

という疑問を持たれたかもしれません

Slide 16

Slide 16 text

だいたい正解です

Slide 17

Slide 17 text

重要なのはあくまでも 適切な組み合わせ

Slide 18

Slide 18 text

- Container - Serverless

Slide 19

Slide 19 text

サービスの提供形態で クラウドを整理してみる

Slide 20

Slide 20 text

簡単に言うとIaaS/PaaS/SaaS

Slide 21

Slide 21 text

出典: https://codezine.jp/article/detail/8051

Slide 22

Slide 22 text

さらに最近だとCaaS/FaaS/**asS

Slide 23

Slide 23 text

PaaS全般をあわせて サーバーレスとして扱います

Slide 24

Slide 24 text

Lambdaだけがサーバーレスじゃない

Slide 25

Slide 25 text

メリット

Slide 26

Slide 26 text

コンテナのメリット ※ 実行筐体に関わらず - コンテナ自体はImmutable Infrastructure - コンテナプールは、Resource Utilization

Slide 27

Slide 27 text

サーバーレスのメリット ※ サーバーレスの種類にかかわらず - 実体としてのリソースを管理しなくていい - あるいは管理が楽

Slide 28

Slide 28 text

“Manage-less” infrastructure

Slide 29

Slide 29 text

サービスとしてどこまで触れるか？

Slide 30

Slide 30 text

サービスとしてどこまで触れるか？ = どこまで管理しなければならないか

Slide 31

Slide 31 text

極力自分で管理しなければならないものを 減らし、本来重要なところに集中する

Slide 32

Slide 32 text

本来取り組むべきは・・・ - アプリケーションのビジネスロジック - クリティカルな部分のインフラ - サービス全体での可用性 - etc.

Slide 33

Slide 33 text

要は、楽したい

Slide 34

Slide 34 text

楽をしつつも可用性を向上させたい

Slide 35

Slide 35 text

例えば、サーバー１台立てると

Slide 36

Slide 36 text

例えば、サーバー(VM)１台立てると - OS/ミドルウェアのセキュリティ・バウフィックスの定期的なパッチ - プロビジョニング方式や再現性 - 負荷分散、冗長化・・・ - アプリケーションのディプロイ - 各種ログの収集 - 法令、業界や会社の規制

Slide 37

Slide 37 text

めんどくさい

Slide 38

Slide 38 text

ちょっとしたサーバーも、 ビジネスレベルで運用するなら 考慮することが多すぎる

Slide 39

Slide 39 text

サーバーを立てたら負け

Slide 40

Slide 40 text

とまでは言わないが、 その後の運用を覚悟しなければならない

Slide 41

Slide 41 text

こんなことないですか？ - gli○cやopen○s○のような脆弱性パッチ当てに追われる - 昔に立てたWord○ressを定期的にメンテナンスしなければならない - どこで動いてるかもわからないディプロイボットを定期的に面倒を見なければならな い - カジュアルに立てたRe○ashが、クリティカルに使われる - 気づいたらログが欠損していて復旧に追われる - etc.

Slide 42

Slide 42 text

管理するべき対象や物事が多すぎる

Slide 43

Slide 43 text

もちろん すべてインフラ面で解決しなきゃならないわ けではない

Slide 44

Slide 44 text

不要なものは捨てるのが一番

Slide 45

Slide 45 text

それでも管理するものはなくならない クラウドをつかって楽をする

Slide 46

Slide 46 text

※こんな場合には当てはまらないかも - インフラエンジニアが何十人もいる - ネットワーク/OS/各種ミドルウェア等のレイヤーごとに専任がいる - Netflixバリに完成度の高いプラットフォームを自社で有している

Slide 47

Slide 47 text

What you need to consider in cloud

Slide 48

Slide 48 text

クラウドで考慮すべきこと - ワークロード - クリティカル度合い - ベンダーロック

Slide 49

Slide 49 text

ワークロードから考えてみる

Slide 50

Slide 50 text

ワークロード - どういうワークロードなのか - イベントドリブン - Httpトラフィック - Heavy? Light? - リソース - CPU/Memory/Disk... - 実行するために何が必要なのか - ミドルウェア

Slide 51

Slide 51 text

クリティカル度合い

Slide 52

Slide 52 text

クリティカル度合い - ビジネス上の重要度 - サービスでの利用のされ方 - 技術的要件 - 許容レイテンシ

Slide 53

Slide 53 text

ベンダーロック

Slide 54

Slide 54 text

ベンダーロック - 組織としてのベンダーとの付き合い方 - どこまで許容するのか - サポート形態 - そもそもベンダーを変えることがあるのか - 開発フローを阻害しないか - ローカル開発

Slide 55

Slide 55 text

Cases

Slide 56

Slide 56 text

実際の事例をいくつか

Slide 57

Slide 57 text

※弊社のユースケースにおいての技術選 定であって、特定のクラウドを勧めてるわけ ではありません

Slide 58

Slide 58 text

Case1. FaaS Deploy/Event Notification Function

Slide 59

Slide 59 text

Notification function on FaaS LambdaやCloud Functions - ワークロード - SNSやPubSubなどのイベントをフックに発火 - クリティカル度合い - ミリ秒単位で争うわけではない - ベンダーロック - 各関数はベンダースペシフィックに書く必要がある - ベンダーごとの言語の縛り

Slide 60

Slide 60 text

Notification function on FaaS LambdaやCloud Functions - ワークロード - 常時プロセスを起動させておく必要はない - クリティカル度合い - 自前サーバーでイベントを受けても対して速さは変わらない - ベンダーロック - 関数自体大した量じゃない - 頻繁にディプロイするわけでもない

Slide 61

Slide 61 text

Case2. CaaS Deploy bot on GKE Redash on GKE

Slide 62

Slide 62 text

Deploybot on Kubernetes - ワークロード - Slack RTMの通信を常時行う - クリティカル度合い - 死ぬとディプロイやロールバックができない - ベンダーロック - 特になし

Slide 63

Slide 63 text

Deploybot on Kubernetes - ワークロード - プロセスを起動し続ける必要がある - クリティカル度合い - 最低限オーケストレーション はちゃんと行いたい - ベンダーロック - ベンダーとしての選択肢が豊富かつ 載せ替えも容易 - GKE/EKS/Azure/Oracle/自前etc… - コンテナなのでローカル環境も構築しやすい

Slide 64

Slide 64 text

Redash on Kubernetes - ワークロード - それなりにヘビーなトラフィック - プロセスは常時起動 (Web/Worker) - クリティカル度合い - オーケストレーションはちゃんとしたい - ベンダーロック - 省略

Slide 65

Slide 65 text

あるPaaSのすべての機能を使いこなす必要はない 例) Kubernetes ユースケースによっては、コンテナのオーケストレーションをやってくれさえすれば良い

Slide 66

Slide 66 text

Case3. PaaS Data pipeline Data warehouse

Slide 67

Slide 67 text

Data Pipeline via PubSub and Dataflow https://cloud.google.com/dataflow/?hl=ja

Slide 68

Slide 68 text

Data Pipeline via PubSub and Dataflow - ワークロード - 複数のアプリケーションサーバーから送られるログを BigQueryに入れる - クリティカル度合い - 欠損時はビジネス上の意思決定、アプリケーションのアルゴリズムともに影響受ける - ベンダーロック - 完全にGCPロックイン

Slide 69

Slide 69 text

Data Pipeline via PubSub and Dataflow - ワークロード - とにかくログが多い - クリティカル度合い - 欠損が許容されない - ベンダーロック - fluentdやkafkaを自前で運用するよりはパイプラインとしてよっぽど安定する - (GCPで障害になることもあるが ) - DataflowのApacheBeamは一応オープンソース

Slide 70

Slide 70 text

BigQuery as DataWarehouse and Analytics Engine - ワークロード - PBクラスのデータを保持 - TB/PBオーダーでの解析 - クリティカル度合い - 省略(DataPipelineと同じ) - ベンダーロック - 自前運用が事実上不可 - 完全にGCPロックイン - 載せ替えれないこともないが膨大なデータの移動とクエリの書き換え

Slide 71

Slide 71 text

Case3. IaaS Elasticsearch

Slide 72

Slide 72 text

それでもIaaS (VM)を使う場合もある

Slide 73

Slide 73 text

Elasticsearch

Slide 74

Slide 74 text

- サービス上クリティカルな部分(検索)で使用している - PaaS(Elasticsearch Service/ElasticCloud)もあるが - 書き込み頻度が高く耐えられない - レイテンシーが許容できない - IaaS(EC2)で運用 - OSレベル、JVMレベルの事柄との付き合い Elasticsearch

Slide 75

Slide 75 text

- 以前EC2で運用していたMySQLはRDS Auroraに載せ替え - メンテナンス性、可用性を考慮し ちなみに

Slide 76

Slide 76 text

QED?

Slide 77

Slide 77 text

これですべて解決するか？

Slide 78

Slide 78 text

考えることがむしろ増えていないか - 確かに増えている - クラウドに知識やオペレーションの習得 - セキュアなコンテナの作り方 - etc. - クラウドの知識は - サポートやハンズオンでもどうにかなる - コンテナの知識は - それなりに汎用的に使えるので覚える

Slide 79

Slide 79 text

エントロピー - 最初は覚えることが多い - 最初はオペレーションもなれない - 技術選定したうえで徐々に下げていくしかない

Slide 80

Slide 80 text

コストは？

Slide 81

Slide 81 text

コストは? - 当然考慮すべき - IaaSよりもPaaSを使うほうがコスト高にの傾向 - 人的コストや可用性との天秤

Slide 82

Slide 82 text

Conclusion

Slide 83

Slide 83 text

Conclusion - 本来すべきことに重きを置き、楽できるところは楽する - 何でも自分で用意する必要はない - 重要なことはサービスに応じて適切な組み合わせを取る

Slide 84

Slide 84 text

Thank you