Manage-less Infrastructure with Container and Serverless

DevOpsDaysTokyo 2018

Transcript

1. "Manage-less" Infrastructure with Container and Serverless DevOpsDays Tokyo 2018 @sakajunquality
2. About Me - SRE at eureka, Inc. - Web系インフラエンジニア - ネットワークとか低レイヤーなとこ ろも好きです @sakajunquality
3. Agenda - Prologue - About“Manageless”Infrastructure - Things to consider - Cases - Conclusion
4. Prologue
5. 本題の前に・・・
6. この発表タイトルを見て
7. GAEじゃだめなの？
8. RDSつかってればいいんでしょ？
9. サーバーレス＝Lambdaでしょ？
10. コンテナ?Docker?
11. Kubernetesの話？
12. サービスメッシュ？
13. Cloud Native？
14. ベンダーロック?
15. という疑問を持たれたかもしれません
16. だいたい正解です
17. 重要なのはあくまでも 適切な組み合わせ
18. - Container - Serverless
19. サービスの提供形態で クラウドを整理してみる
20. 簡単に言うとIaaS/PaaS/SaaS
21. 出典: https://codezine.jp/article/detail/8051
22. さらに最近だとCaaS/FaaS/**asS
23. PaaS全般をあわせて サーバーレスとして扱います
24. Lambdaだけがサーバーレスじゃない
25. メリット
26. コンテナのメリット ※ 実行筐体に関わらず - コンテナ自体はImmutable Infrastructure - コンテナプールは、Resource Utilization
27. サーバーレスのメリット ※ サーバーレスの種類にかかわらず - 実体としてのリソースを管理しなくていい - あるいは管理が楽
28. “Manage-less” infrastructure
29. サービスとしてどこまで触れるか？
30. サービスとしてどこまで触れるか？ = どこまで管理しなければならないか
31. 極力自分で管理しなければならないものを 減らし、本来重要なところに集中する
32. 本来取り組むべきは・・・ - アプリケーションのビジネスロジック - クリティカルな部分のインフラ - サービス全体での可用性 - etc.
33. 要は、楽したい
34. 楽をしつつも可用性を向上させたい
35. 例えば、サーバー１台立てると
36. 例えば、サーバー(VM)１台立てると - OS/ミドルウェアのセキュリティ・バウフィックスの定期的なパッチ - プロビジョニング方式や再現性 - 負荷分散、冗長化・・・ - アプリケーションのディプロイ - 各種ログの収集 - 法令、業界や会社の規制
37. めんどくさい
38. ちょっとしたサーバーも、 ビジネスレベルで運用するなら 考慮することが多すぎる
39. サーバーを立てたら負け
40. とまでは言わないが、 その後の運用を覚悟しなければならない
41. こんなことないですか？ - gli◦cやopen◦s◦のような脆弱性パッチ当てに追われる - 昔に立てたWord◦ressを定期的にメンテナンスしなければならない - どこで動いてるかもわからないディプロイボットを定期的に面倒を見なければならな い - カジュアルに立てたRe◦ashが、クリティカルに使われる - 気づいたらログが欠損していて復旧に追われる - etc.
42. 管理するべき対象や物事が多すぎる
43. もちろん すべてインフラ面で解決しなきゃならないわ けではない
44. 不要なものは捨てるのが一番
45. それでも管理するものはなくならない クラウドをつかって楽をする
46. ※こんな場合には当てはまらないかも - インフラエンジニアが何十人もいる - ネットワーク/OS/各種ミドルウェア等のレイヤーごとに専任がいる - Netflixバリに完成度の高いプラットフォームを自社で有している
47. What you need to consider in cloud
48. クラウドで考慮すべきこと - ワークロード - クリティカル度合い - ベンダーロック
49. ワークロードから考えてみる
50. ワークロード - どういうワークロードなのか - イベントドリブン - Httpトラフィック - Heavy? Light? - リソース - CPU/Memory/Disk... - 実行するために何が必要なのか - ミドルウェア
51. クリティカル度合い
52. クリティカル度合い - ビジネス上の重要度 - サービスでの利用のされ方 - 技術的要件 - 許容レイテンシ
53. ベンダーロック
54. ベンダーロック - 組織としてのベンダーとの付き合い方 - どこまで許容するのか - サポート形態 - そもそもベンダーを変えることがあるのか - 開発フローを阻害しないか - ローカル開発
55. Cases
56. 実際の事例をいくつか
57. ※弊社のユースケースにおいての技術選 定であって、特定のクラウドを勧めてるわけ ではありません
58. Case1. FaaS Deploy/Event Notification Function
59. Notification function on FaaS LambdaやCloud Functions - ワークロード - SNSやPubSubなどのイベントをフックに発火 - クリティカル度合い - ミリ秒単位で争うわけではない - ベンダーロック - 各関数はベンダースペシフィックに書く必要がある - ベンダーごとの言語の縛り
60. Notification function on FaaS LambdaやCloud Functions - ワークロード - 常時プロセスを起動させておく必要はない - クリティカル度合い - 自前サーバーでイベントを受けても対して速さは変わらない - ベンダーロック - 関数自体大した量じゃない - 頻繁にディプロイするわけでもない
61. Case2. CaaS Deploy bot on GKE Redash on GKE
62. Deploybot on Kubernetes - ワークロード - Slack RTMの通信を常時行う - クリティカル度合い - 死ぬとディプロイやロールバックができない - ベンダーロック - 特になし
63. Deploybot on Kubernetes - ワークロード - プロセスを起動し続ける必要がある - クリティカル度合い - 最低限オーケストレーション はちゃんと行いたい - ベンダーロック - ベンダーとしての選択肢が豊富かつ 載せ替えも容易 - GKE/EKS/Azure/Oracle/自前etc… - コンテナなのでローカル環境も構築しやすい
64. Redash on Kubernetes - ワークロード - それなりにヘビーなトラフィック - プロセスは常時起動 (Web/Worker) - クリティカル度合い - オーケストレーションはちゃんとしたい - ベンダーロック - 省略
65. あるPaaSのすべての機能を使いこなす必要はない 例) Kubernetes ユースケースによっては、コンテナのオーケストレーションをやってくれさえすれば良い
66. Case3. PaaS Data pipeline Data warehouse
67. Data Pipeline via PubSub and Dataflow https://cloud.google.com/dataflow/?hl=ja
68. Data Pipeline via PubSub and Dataflow - ワークロード - 複数のアプリケーションサーバーから送られるログを BigQueryに入れる - クリティカル度合い - 欠損時はビジネス上の意思決定、アプリケーションのアルゴリズムともに影響受ける - ベンダーロック - 完全にGCPロックイン
69. Data Pipeline via PubSub and Dataflow - ワークロード - とにかくログが多い - クリティカル度合い - 欠損が許容されない - ベンダーロック - fluentdやkafkaを自前で運用するよりはパイプラインとしてよっぽど安定する - (GCPで障害になることもあるが ) - DataflowのApacheBeamは一応オープンソース
70. BigQuery as DataWarehouse and Analytics Engine - ワークロード - PBクラスのデータを保持 - TB/PBオーダーでの解析 - クリティカル度合い - 省略(DataPipelineと同じ) - ベンダーロック - 自前運用が事実上不可 - 完全にGCPロックイン - 載せ替えれないこともないが膨大なデータの移動とクエリの書き換え
71. Case3. IaaS Elasticsearch
72. それでもIaaS (VM)を使う場合もある
73. Elasticsearch
74. - サービス上クリティカルな部分(検索)で使用している - PaaS(Elasticsearch Service/ElasticCloud)もあるが - 書き込み頻度が高く耐えられない - レイテンシーが許容できない - IaaS(EC2)で運用 - OSレベル、JVMレベルの事柄との付き合い Elasticsearch
75. - 以前EC2で運用していたMySQLはRDS Auroraに載せ替え - メンテナンス性、可用性を考慮し ちなみに
76. QED?
77. これですべて解決するか？
78. 考えることがむしろ増えていないか - 確かに増えている - クラウドに知識やオペレーションの習得 - セキュアなコンテナの作り方 - etc. - クラウドの知識は - サポートやハンズオンでもどうにかなる - コンテナの知識は - それなりに汎用的に使えるので覚える
79. エントロピー - 最初は覚えることが多い - 最初はオペレーションもなれない - 技術選定したうえで徐々に下げていくしかない
80. コストは？
81. コストは? - 当然考慮すべき - IaaSよりもPaaSを使うほうがコスト高にの傾向 - 人的コストや可用性との天秤
82. Conclusion
83. Conclusion - 本来すべきことに重きを置き、楽できるところは楽する - 何でも自分で用意する必要はない - 重要なことはサービスに応じて適切な組み合わせを取る
84. Thank you