はじめに
行ってきた。
感想
- とにかくいいイベントだった！満足感高い
- ひとの数も多すぎない、参加者は500人程度、ストレスは感じなかった
- 小さいながらも充電スペースや、コーヒーも飲めたりとうれしい配慮
- 何より発表内容！自分自身が興味が強いのもあるが、全セッション見るイベントはなかなかない（たいてい1つ休憩する）
- 8割型Kubernetesだったとはいえ、コンテナ/コンテナオーケストレーションのプロダクション導入事例にみんな飢えてるのは感じた（自分もそうだ）
- コンテナを含む、アプリケーションプラットフォームは、kubernetesがデファクトとはいえ、まだまだ混沌としていて、少なくとも2,3年は試行錯誤が続きそうな気がした
- Yahoo(Z Lab)さん、CyberAgentさん、まずOpenStackが安定稼働しているところがすごい、これは他社は真似できない
- だからこそOpenStackの上でkubernetes-as-a-serviceができる
- 見たどのセッションもいろんな視点でkubernetes(コンテナ)を見ていて、自分自身これからどうやって活用していくかに役立つ
- pivotal草間さんのセッションが印象に残った、「適材適所」だがそれが難しい
- コンテナも、kubernetesも所詮技術、ビジネス解決に何が適しているかを見極めるのがエンジニアリング
- そのためにはServerlessも、PaaSも、Container Orchestrationも、"正しく理解"しなければならない
- 最後Zlab五十嵐さんの発表、なんであんなにスライドきれいなんですか。。。
- istio触りたくなる見事な発表でした
- 今後もkubernetesを自分も触っていくが、アプリケーションの信頼性、ひいてはアプリケーションが解決するビジネス課題のために技術があるという視点は忘れないようにしたい
- 次回は12月！参加したい！
公式さんがまとめてくれる前に、@Yukotanさんが資料をまとめてくれています、助かります！
以下、メモです。
サイバーエージェントにおけるプライベートコンテナ基盤AKEを支える技術[Masaya Aoyama(CyberAgent)]
AKE(Adtech Container Engine)
2人で作ったとのこと
構築
- パッチをあてたkubernetesバイナリをビルド、packerでqcow2に。
- その後heatで展開
- バージョン依存、くみあわせ、kubernetes, docker, etcd,,,
- E2E test
key機能
- kubernetes, swarm(multi COO)
- openstack integration
- high performance
- add-on mechanism(monitoring, logging), datadog, kibana, elastic
- tuning for adtech system
multi container runtime
まとめ
- Pros
- なんでもできる
- kubernetes最高
- add-techに特化したkubernetes環境を作れる
- オンプレなので、パブリッククラウドとのハイブリッド構成もできる
- cons
- 実装コストが大きい
- 運用コストが大きい
- 内部実装を理解する必要がある
- Pros
- あくーえちゃんの飼い主、we are hiring
- KubeCon 2018 EU 日本交流会＠コペンハーゲン
マイクロサービスアプリケーションとしての機械学習[Takuma Yamaguchi(Mercari)]
画像認識を中心とした機械学習
機械学習基盤の現状と課題
- 要求性能が高い
- サーバコストが高い
- 学習モデルと、ソースコードのバージョンを合わせるのは面倒
- プロダクション以外にも学習環境が必要
機械学習を使った新機能をリリースしたい、インフラ担当ならどうする？
回答「とりあえずdockerfileを書いてください、なんとかします」
Dockerfileはじめて書いた、シェルスクリプト感覚で1日で書けた
1週間後、動きました
なんで一週間でできたのか
- 複数の開発拠点(日本、サンフランシスコ、ロンドン)
- マイクロサービス化していて、影響範囲が明確になっていた
今までは「手順書を用意してくれれば構築します」だった、運用の限界は見えていた
機械学習におけるMicroservicesのメリット
まとめ
- 実行環境や運用が特殊なことが多くMicroservicesとの親和性が高い
- 影響範囲の明確化
- アルゴリズム選択の自由
- 実行環境や運用が特殊なことが多くMicroservicesとの親和性が高い
200GBのモデルなんですけど -> 苦笑いながら「とりあえずdockerfileをもってきて」
"Yahoo! JAPANのKubernetes-as-a-Service"で加速するアプリケーション開発[Masaya Ozawa(Yahoo! Japan)&Kazuki Suda(Z Lab)]
www.slideshare.net
Yahoo!ズバトク on kubernetes
- おとくなくじやキャンペーンを掲載するためのキャンペーンプラットフォーム
- yahooズバトクの技術スタック：openstack, jenkins, 社内独自パッケージシステム、php
- 課題
- スケールアウト、スケールアップができない
- リリース自動化ができてない
- パフォーマンステストのための本番同等の環境がなかった
- kubernetesを使おう
- Kubernetes移行
- 考え方、設計方針のスイッチ
- Cloud Native的な考え方
- 考え方、設計方針のスイッチ
Yahoo Japanのkubernetes as a service
- zlabのkaasについて
- セルフサービス
- オートヒーリング
- ゼロダウンタイムアップグレード
- クラスタアドオン
- kaasの価値
- 煩雑なkubernetesのオペレーションから運用者を解放する
- AUTOMATE ALL THE THINGS
- kaasの要件
- スケーラブル、管理対象が数万台でも動く
- 非同期モデル、マシン(VM)準備など処理完了まで時間かかることも
- 堅牢性
- CustomResourceDefinitions(CRD)
まとめ
- kaas導入によりビジネスロジックに集中できるように
- ソフトウェアですべてを自動化
- kubernetes-as-a-service on kubernetes
Kubernetes x PaaS - コンテナアプリケーションのNoOpsへの挑戦[Yoichi Kawasaki(Microsoft)]
www.slideshare.net
- venture -> yahoo -> microsoft
- cloud app dev専門
- NoOps
- システムに自立運用（自己回復性）をもたせて運用コストを最小限にする
- エンドユーザーにとってはサービス停止時間が最小に、高いサービスレベルを享受
- 運用担当にとってもSRE的な運用機能に注力
- デブサミ2018 NoOps
- https://www.slideshare.net/hiromasaoka/noops-88082246
-
特徴
- self healing
- in-flight renewing(無停止メンテ)
- adaptive scale
kubernetes
- self healing
- pod's phase
- probe
- lieness 生きているかどうか、再起動の判断
- readiness probne トラフィック受付可能かどうか、通信先決定の判断
- restart policy、再起動判断
- deploymentとreplicasetの仕組み
- in-flight renewing
- deployment配下を段階的に入れ替える
- autoscale
- podのhorizontal pod autoscale(HPA)
- cluster autoscaler(CA0 クラスタレベルのオートスケール
- node追加する
- リソース不足でこれ以上podを増やせなくなった動く
- self healing
- マネージドサービス、PaaS、Serverlessを活用？
- kubernetesは強いけど向かない例もあるよね
- 無理にしなくていいよ
- Kelsey Hightowerさん
- ステートフルなもの、StatefulSetsやVolumesとかあるけど、まだまだ経験が必要な段階
- こういうのはプラットフォームとして回復性がネイティブ実装されたPaaSやServerlessを可能なかぎり選ぶべき
- Open Service Broker API
- もともとCloud Foundryで考えられたものを汎用化
- 外部サービスのprovisioning、更新、削除、bindingなどを自動化
- Service Catalog
- kubernetesがService Brokeと簡単に連携する
- kubernetesはService Catalogを通じて、OpenService Broker APIともしもしし、Service Broker(各種ベンダ製プラットフォーム)とやりとりする
- AWSのRDS(MySQL)を使う例
- credentialな情報はSecretへ
- マネージド型kubernetesの活用
- クラスタフリー＆サーバレスコンテナサービス
- k8sのクラスタは作らない、コンテナイメージを使いたい、使った分だけ課金
- https://github.com/virtual-kubelet/virtual-kubelet
- nodeのように見えるvirtual-kubelet
- Service Mesh
- Service間通信の課題を解決するソフツェアレイヤー
- コードを変更することなく回復性機能を追加できる
- podの中でenvoyをサイドカー的にいれて、プロキシ的振る舞い
- 1行かけばバグは生まれる、コーディングレスにこしたことはない
- CI/CDは重要
- モニタリングとログ収集
- クラスタ全体で何が起きてるかを把握できることが重要
- それに対してテクノロジ選択、いろいろあります
- Cloud Native Landscape
- エコシステム広大
- まとめ
- kubernetes非常に強力だけど完璧じゃない
- オフロードが可能であるなら回復力がもったマネージド、Paas、serverless活用
- 足りない部分はエコシステムを活用して賢くギャップを埋めよ
- NoOpsの目的は運用負荷を最小にして空いた時間をさらなるイノベーションに埋めよう
Cloud Native Apps入門[Takuya Noguchi(iRidge/dockerjp)]
- @tnir
- アプリケーションエンジニアに普段からClod Native Appを使ってほしいな
Cloud native appsとは
- CNCF
- Container packaged -> containerization
- Dynamically managed -> orchestration
- Micro-services oriented -> service mesh
- 20プロジェクトある
- 昨年kubernetesがgraduate
- CNCF CI dashboard
- certification kubernetes認定プログラム
- 個人の認定資格もある, administratorとdevelopper
- cloud aoolication maturity
- twelve factor app
- GitLab CI評価高い
- ソースはどれだろ
まとめ
- どんなワークロードでもkubernetesで実行できる世界を目指しましょう（アプリのcloud native化）
- cloud nativeなアプリを開発していける仕組み化が重要（？
- ciはまだデファクトがない？
- スタートとしてmicroservicesにこだわらないことも大事
- コミュニティの皆様に支えられてやってこれ、社内のコンテナ標準化ができた
Spinnakerを利用したKubernetesへの継続的デリバリ[Takashi Mizouchi(AP Communications)]
- APCommunication、7割がインフラエンジニア
- ミランティスとのジョイントベンチャー、ミランティス・ジャパン株式会社
- コンテナのメリット
- ポータビリティ、別環境で実行可能
- 軽量、VMイメージより軽い
- 実行環境の隔離
- コンテナの管理、以下の課題をkubernetesが解決
- 複数のDockerホストの管理
- コンテナの死活監視
- 障害発生時のセルフヒーリング
- ロードバランサー
- 永続的なデータ管理
- ログの管理
- kubernetesでも解決が難しい問題？
- CI/CDの機能がない
- SpinnakerはCDツール。kubernetesをdeployできる。
- Spinnekerの特徴
- マルチクラウド対応CDツール
- openstack, azure, aws, google app engine, oracle cloud DC/OS, kubernetes
- 自動デプロイに必要な機能を搭載
- パイプライン、
- 様々なdeploy方法
- blue/green deploy
- rolling deploy
- canary deploy
- GUIでパイプライン（ワークフロー）を作成できる
- パイプライン中にカスタムスクリプトの実行が可能
- serverspecとか
- 他のパイプライン(jenkinsやgitlab-ci)でもできそうな気がする。。。
- パイプライン中にカスタムスクリプトの実行が可能
- 連携できるCIツールはJenkinsとtravisCI
- manual jadgementはよさそう
- write-listed execution windows
- よく使う時間（日中、9時ー17時とか）をデプロイ禁止にできる
- chaos monkey integration - ツールがついてる？そう動くんだろ
- enable monitoring
- datadog
- prometheus
- stackdriver
- spinaker <->k8sのマッピング
- 名称をマッピングさせる必要がある
- 今後
- マルチクラウド対応CDツール
Helmを利用したKubernetes as a Serviceの実装[Motohiro Otsuka(NEC Solution Innovators)]
- keynoteのyahooさんとかぶって、、、
- 自前で運用してたけど、運用したくない！
- kubernetesはクラウドネイティブなアプリケーションの運用管理基盤
- helm、kubernetesのパッケージマネージャ
- 一般的なアプリケーションですらmanifest書いてた
- chartって単位で共有できる
- https://kubeapps.com
- kubernetes as a serviceは、ユーザごとにクラスタを提供する
- クラウドに対抗するkaasを出すには？
- コントロールプレーンのデプロイ、管理を自動化する
- kubernetesがあるのでは？
- kubernetes on kubernetesですよね
- 自然な発想ですよね
- kubernetesだってクラウドネイティブアプリケーションですし
-
Google Kubernetes Engineにおけるバッチ処理のパターン[Shota Yoshikai(Kabuku)]
- バッチ処理
- 数秒から数時間以上かかる処理
- 非同期
- バッチ処理パターン
- kubernetes標準のジョブ
- メッセージキューイングの組み合わせ
- kubernetesのjob
- 一度切りの処理を実行させるコンテナ
- ジョブのみを使う構成
- メリット、シンプルでいい
- デメリット
- ジョブの数が増えると管理が大変、labelつけてもいいけどつら
- 一度に大量のジョブを作るとリソースの上限に達してしまう
- 公式での解決策
- parallel processing using expansions
- rabbitmqやredisと組み合わせる
- MQと組み合わせる
- 検討すべき点が増える、MQのサービスどれ使うか
- pushかpullか
- ネットワーク構成
- クラウドのMQ
- GCP、Cloud Pub/Sub
- フルマネージド
- 負荷は札束で殴って解決
- 通信経路がk8sのネットワーク外
- 経路：client -> Cloud Messqge Queue -> k8s pod
- ミドルウェアのメッセージキューイング
- rabbit mqとか
- 経路：client -> k8s middleware message queue -> k8s pod
- k8sに中にいる
- 構築例
- いろいろあって、、、いけてないところも、、、
- 課題、httpやめたい
- 検討したもの
- Cloud Pub/Sub ACKの期限が最大10分
- Cloud Tasks、アルファなので本番使えない
- Redis、シンプルで早いけど必要な機能たりない
- RabbitMQ、重いけど多機能。かわいい
- まとめ
『コンテナ疲れ』と戦う、k8s・PaaS・Serverlessの活用法！[Kazuto Kusama(Pivotal)]
- アンケートによると参加者の46%がコンテナを商用活用してる、、、？
- そんなわけじゃないよね
- 参加者偏ってる、選りすぐり、それでも46%
- 平日昼間に参加可能
- 5000円も払ってきてる
- ゴール：正しいテクノロジースタックを選択してもらう知識を得てもらう
- なんでコンテナが普及しないのか？
- コンテナ技術、楽しいよね
- コンテナいれると幸せになれましたか？
- コンテナいれて業務は劇的に改善した
- コンテナ辛い
- Dockerfileつらい
- 教えるのもつらい
- コンテナ技術は抽象度が低い、エンジニアがカバーする必要あり
- kubernetesはgoogleのborgが元、すばらしいけどエンジニアのスキルの高さが前提
- SREも同じ、日本でやるには熱意と覚悟が必要
- テクノロジーの流れ
- 高い抽象化と自動化の繰り返し
- 一度抽象化、自動化したものが戻ることはない
- コンテナの次になにがくる？
- より高度に抽象化、自動化されたもの
- Dockerfile書かなくていい
- 運用もみてくれる
- 何も指定しなくても勝手にスケールしてくれる
- あれ？
- PaaS？昔からあるような？
- Herokuは2007年
- CloudFoundryは2011年
- PaaSの多くは内部でコンテナ技術使ってるから、時代遅れとかじゃないよ
- Serverless、コンテナ関係ない、、、？そうではない
- CaaS、PaaS、Serverless、何を採用すべきか？
- [CNCF Serverless Whitepapter](https://github.com/cncf/wg-serverless/tree/master/whitepaper
- 目的をしっかり考えよう
- 強靭性
- スケーラビリティ
- ステートレス、ステートフル
- アプリの更新頻度
- 既存資産の流用
- Dev, Opsの人数
- 潜在的なコストを考慮しよう
- 誰もがイチからアプリを作れる恵まれた環境にいるわけではない
- lift & shiftは楽だけど長期的にはコストかかるかも？
- Serverless化するとインフラコストは下がるけど、アプリ書き換えコストに見合うとは限らない
- ServerlessはRDBとの相性が良くない、LambdaだとDynamoDBのほうが向いてる
- PaaSやserverlessはopinionated。プラットフォームにあわせて開発しないといけない、その代わり合わせると生産性はあがる
- kubernetesはless-opinionated。自由度は高いが、、、生産性は？
- Serverlessは究極のロックイン（今のところ）
- コード自体は一般的な言語が使えるし、フレームワークもあるが
- 仕組み上他サービスと組み合わせるので結果ロックイン
- ロックインが別に悪いってわけじゃない
- 得意不得意があるので組み合わせよう
- ただし自動化はしっかりしよう
- 「戦うWebデザイン」制約は創造性をはぐくむ
- railsの設定より規約
- 適度な制約があると本来すべきことに注力し、創造性、生産性を高められる
Istioと共にマイクロサービスに立ち向かえ![Aya Igarashi(Z Lab)]
- Istioの解決方法
- Microserviceにありがちな問題
- Microservices
- よくあるモノリシックとの比較
- スケールアウトしやすい
- 変更しやすい
- 大人数で開発しやすい
- 銀の弾丸ではない、複雑になる
- 複雑なサービスメッシュの管理が追いつかない、という問題を解決するOSS
- サービスメッシュ：アプリケーション間でメッシュ上に交差するネットワーク
- ServiseMeshを制御しきれない問題
- アプリケーションのコードにServiceMeshの設定が埋め込まれている場合
- 修正毎に再デプロイ
- 運用、開発双方に負荷
- ServiceMeshの設定を分離
- k8sにappをdeploy
- k8s、init containr、iptableを書き換える
- containers、app+envoyを立てる
- アプリケーションのコードにServiceMeshの設定が埋め込まれている場合
- ServiseMeshを制御しきれない問題
- 鍵と証明書を管理しきれない問題
- システムによってはアプリケーション間通信の暗号化は必須、、、
- 鍵と証明書の生成、配布、更新、廃止に対応
- 鍵と証明書を管理しきれない問題
- システムの全体像が把握できない問題
- ドキュメントは更新されなくなるよね
- 可視化ツールとの連携
- metrics prometheus/grafana
- traces: zipkin
- ServiceGraph Graphbiz/Prometheus
- システムの全体像が把握できない問題
障害発生時に何が起こるかわからない問題
- 障害を起こすテストを起こすのはコストがかかる
- 結局障害が起こるまで対策が打たれない
- Fault Injection(chaos enginering)
- Circuit Brakerで被害を最小限
- 前段のアプリはタイムアウトをずっと待ったりしない
- istio入門チャート
- GKEがらく
- quickstartを参考にistioインストール
- こまったとき
- トラシューガイド
- FAQ(めっちゃ充実)
- StackOverFlowやGitHubのIssue
