コンテナ管理とサーバーレス on GoogleCloud

Transcript

1. コンテナ管理とサーバーレス on Google Cloud Cloud Native Hiroshima #01
2. 森藤　敏之（もりとう） - @mmorito_0318 所属 - 株式会社エムネス - 遠隔画像診断センター - 医療支援サービス「LOOKREC」 イベント / 勉強会 - GCPUG - 広島支部 organizer - 中国DB勉強会 - 広島担当 - JP_Stripes - 広島 - Cloud Native JP - 広島 - その他
3. Kubernetesの導入事例
4. Kubernetesの導入事例 医用画像ファイルの変換処理
5. DICOMファイル - DICOMファイル（.dcm） - CT、MR CR - 画像データとその他メタ情報のデータセット - 1検査が平均300枚くらいで構成される身体のスライス画像 - 致命的な欠点: 自分自身が合計何枚かを知らない 500KB 30MB
7. DEMO
10. あんまり参考にならない なぜなら多分これは 一般的な用途ではないから。
11. 一般的な用途 そもそもKubernetesを使う状況とは。
12. サーバー データベース キャッシュ 一般的な用途
13. データベース キャッシュ カスタマー向けサーバー クライアント向けサーバー クライアント向けサーバー LB 一般的な用途
14. クライアント向け カスタマー向け データベース キャッシュ メンテナンス（管理者）向け LB
15. ビジネス向け カスタマー向け データベース キャッシュ モニタリング メッセージ送信 データ加工（ ETL） DWH AI・ビッグデータ解析 メンテナンス（管理者）向け LB バッチ処理群
16. ビジネス向け カスタマー向け バッチ処理群 データベース キャッシュ モニタリング メッセージ送信 データ加工（ ETL） DWH AI・ビッグデータ解析 メンテナンス（管理者）向け LB
17. ビジネス向け カスタマー向け バッチ処理群 ストレージ データベース キャッシュ モニタリング メッセージ送信 データ加工（ETL） DWH AI・ビッグデータ解析 メンテナンス（管理者）向け LB ビジネス向け カスタマー向け バッチ処理群 ストレージ データ加工（ETL） メンテナンス（管理者）向け LB メッセージ送信
18. つらい つらい。
19. 議論 マイクロサービスというのが良いらしい
20. http://album.cloudit.co.jp/wp-content/uploads/2017/04/MSA1.jpg
21. http://album.cloudit.co.jp/wp-content/uploads/2017/04/microservice.jpg
22. マイクロサービス - サービスに合わせてチームを細分化しやすい - 細分化したチームで意思決定が速い - 変更が他へ影響を与えない - 各チームがスピーディにたくさんサービスを展開
23. 結論 マイクロサービス最高！
24. マイクロサービスとは - サービスに合わせてチームを細分化しやすい - 細分化したチームで意思決定が速い - 変更が他へ与える影響が少ない - 各チームがスピーディにたくさんサービスを展開 !?
25. ビジネス向け カスタマー向け バッチ処理群 データベース キャッシュ モニタリング メッセージ送信 データ加工（ ETL） DWH AI・ビッグデータ解析 メンテナンス（管理者）向け LB
26. 幸せの定義 本当にマイクロサービスは幸せなのか - コンポーネントが細分化されて今まで以上にワークフローが複雑 - どのコンポーネントがどこから呼ばれるのか - デバッグ・デプロイが超絶複雑に
27. つらい どのみちつらい。
28. 複雑になる作業 - アプリケーションの全体像を 把握するのが難しい - 変更時の影響範囲も複雑化 - 毎回全ビルド、全リリース が必要 - コンポーネントが細分化されるため ワークフローが複雑化 - どのコンポーネントが どこから 呼ばれるのか管理が大変 - デバッグ・デプロイが超絶複雑に モノリシック マイクロサービス
29. 幸せになるために 様々なツールを駆使して、ワークフローを自動化しよう
31. Docker サービスのパッケージ化
32. Kubernetes コンテナの管理・運用
33. http://nishadikirielle.blogspot.com/2016/02/kubernetes-at-first-glance.html
34. Istio サービスメッシュの管理
35. http://philcalcado.com/img/service-mesh/mesh3.png
36. https://docs.google.com/presentation/d/1DOvrP3jhUurK3E1NtG2DcRd31qeW65rj98vsspCAY7c/edit#slide=id.p Control Plane API Mixer Service A Service B proxy proxy HTTP/1.1, HTTP/2, gRPC or TCP -- with or without mTLS Pilot Citadel Config data to Envoys TLS certs to Envoys Policy checks, telemetry Control Plane Pilot：サービス通信ポリシーを構成およびプッシュするための制御プレーン。 　　　（タイムアウト・リトライ・サーキットブレーカーなど） Mixier：Envoyからデータを収集し、アクセスコントロールを行う 　　　　プラグインモデルによる柔軟なポリシーの施行が可能 Citadel：アイデンティティと資格情報を管理し、 　　　　 相互TLSを使用したサービス間認証を行う[n,z] Data plane Envoy：通信を傍受してポリシーを適用するネットワークプロキシ
37. Google Cloud の方向性
38. Cloud Services Platform
39. - マネージドIstio - Stackdriver によるサービス監視 - Container Registry, Cloud Build を活用した CI/CD - GKE on-prem によるハイブリット環境の構築 - GKE serverless add-on を使用したエンドポイントの抽象化 Cloud Services Platform
40. https://4.bp.blogspot.com/-S3E4fro-TTI/W14x2CzsTtI/AAAAAAAAGI4/InS86LvJ_-MEaJK7obM7oWNoGF0VFCKQgCEwYBhgL/s1600/gcp_stackdriver_topology.png
41. Knative https://github.com/knative/docs
42. Googleの目指す未来 「最終的には、Google Cloud Functions、Google Kubernetes Engine、 Google App Engineなどの上の全てのアプリケーションが、 Istioのエンドポイントとして同じように見え、管理できなければならない。」 http://www.atmarkit.co.jp/ait/articles/1808/28/news036.html
43. これは誰向けなのか 組織の文化や既存の資産によって ベストプラクティスが大きく変わってくる http://www.atmarkit.co.jp/ait/articles/1808/28/news036.html
44. さいごに エムネスでは、 一緒に新しい技術に挑戦していける仲間を募集しています！
45. ありがとうございました