Japan Container Days v18.04に行ってきました。

はじめまして! コネクトムの草ヶ谷と申します。 これから記事を書いていき、徐々に充実したブログにしていきたいと思っておりますので、どうぞよろしくお願い致します!

で、1発目の記事が勉強会レポートでなにやら微妙な感じもしますが・・・。

4/19(木)にベルサール神田で行われた「Japan Container Days v18.04」というイベントに行ってきました。 そこで聞いてきた内容と、自分の感想をつらつら書いていきたいと思います。

f:id:gyagya1111:20180505134631p:plain

サイバーエージェントにおけるプライベートコンテナ基盤 AKE を支える技

  • アドテクスタジオ独自のプライベートコンテナ基盤(AKE)を作った話
  • 広告に関連するサービス(DSP, SSP, DMP等)を複数展開している
  • 広告業界では「Low Latency」、「High Traffic」、「High Computing」が求められている
  • AKEはOpenStack上に構築されている
  • それらを実現する為に、チューニングを行い高速化もした
  • 自分たちでKubernetesクラスタを作ればなんでも出来るけど、コストが大きい
    • Kubernetes自体に深い理解が必要
    • コンテナに合わせたCI/CDが出来るまでは結構辛かった

セッション全体を通した感想としては、やっていることは非常に高度な事をやっていて刺激を受けた反面、自分の会社でここまでやるのは無理かなと思いました。 受けられる恩恵とプライベートコンテナ基盤を作る労力を天秤にかけると、圧倒的に労力が上回るのではないかと思います。 とはいえ、個人的にはKubernetes使い込んでる感をすごく感じれたセッションだったので、やろうと思えばいろんなことが出来るのがわかり、非常に勉強になりました。

マイクロサービスアプリケーションとしての機械学習

  • メルカリの商品出品時に使われている画像認識機能を作った時の話
  • Kubernetesを使った環境上にデプロイされている
  • マイクロサービス化してあると、機械学習を取り入れやすい
  • モデル作成してストレージに保存するまでの部分と、そのモデルを利用する部分とで分けることで、影響範囲の明確化や、依存関係をそこまで気にする必要がなくなる

機械学習は弊社でも導入する方向性になっているので、このセッションで聞いた内容が役に立つのではないかなと思います。 最初はアプリケーションコードと機械学習モデルが共存しており、片方だけ更新したくても両方更新せざるを得ない状況だったのが、それぞれをマイクロサービス化して切り出すことで、片方だけをデプロイ出来るようにしたそうです。 学習済みのモデルを読み込み専用のPersistent Volumesに保存していて、それを入れ替えるだけでリリースが完了するので、非常に簡単にリリースや切り戻しが出来るようになっているのもよい点だと思いました。

"Yahoo! JAPANのKubernetes-as-a-Service"で加速するアプリケーション開発

  • イベントの日に通常の数倍から数十倍のアクセスが来ることが想定されているが、スケールアウトやスケールアップが出来なくてツラい
  • リリース周りが自動化されていなくてツラい
  • パフォーマンステスト用の環境がなくてツラい
  • VM障害があると影響度がでかくてツラい
  • Z Labさんが提供しているKubernetes-as-a-Serviceを利用するようにして、アプリケーションコードもデプロイフローも全て見直すことで、リリースに掛かる負担を削減した。10分程度でリリース出来るようになった。
  • OpenStack側に障害が起きてもサービスダウンしなくなったし、自動復旧するため特に復旧作業は必要なくなった。
  • ログ収集して可視化するところまで仕組みを作ったので、レポート作成にかかる負担が減った

Kubernetesを利用出来るようになるまでのツラさは想像に難くないのですが、それを乗り越えたおかげで受けれた恩恵も非常にでかそうだという印象を持ちました。

Kubernetesセキュリティベストプラクティス

  • 中身がどうやって動いているのかわかっていない状態で使うのはよくない
  • GKEを使うとセキュリティの高いクラスタが作れる

Kubernetesのセキュリティに関するお話が中心でした。 実際に手を動かしながら見せてくれて、画像で概念的な説明がされていたりと、とてもわかり易い内容でした。 こういったセキュリティ系のセッションを聞くのは初めてだったので、今まで漠然とKubernetesってセキュリティリスクとしてどんなものを抱えているのかわかっていなかったのですが、こういうリスクを抱えているのかということが明確化されて、ちょっとスッキリしました。 もちろんここに書かれていることが全てではないと思いますが、このセッションで聞いた内容を自分で手を動かしながら確かめていきたいと思います。

Container Networking Deep Dive

Kubernetesのネットワークがどうなっているのかを解説してくれていたのですが、正直Kubernetes自体もそんなに触れていない自分には難しすぎたかなと思いました・・・。 一言でまとめると、ちゃんと自分たちが使うものはきちんと理解して使いましょうって感じでした。 確かにその通りで、なんとなく使っていると後々痛い目見るので、少しずつ理解していこうと思います。

Kubernetesの運用設計ガイド

  • Kubernetesを使う目的をはっきりさせる
  • Kubernetes自体の狙いと合っているかを確認する
    • インフラ管理の為の手作業の時間を減らす
    • セルフサービス型の運用を可能にする
  • 技術と組織は表裏一体なので、チーム作りからやる必要がある
  • コンウェイの法則「組織の設計するシステムは、その組織のコミュニケーション構造をそのまま反映した設計になる」を逆手に取って、「作りたいシステムの構造を反映したコミュニケーション及び組織構造を作ると、システムが期待した設計になる」

Kubernetesをどうやって使えばいいのかみたいな話がされるのかと思いきや、いきなり組織づくりがどうこうみたいな話が出てきて、びっくりしました。 コンウェイの法則を逆手に取ってみるという考え方は、とても興味深い考え方だと思いました。 実際に運用していく際の細かい話は結構色々書いていて、ここに書くととんでもない量になるので割愛します。

『コンテナ疲れ』と戦う、k8s・PaaS・Serverlessの活用法

  • 正しいテクノロジースタックの選択が出来る知識があることが大事
  • コンテナ技術は抽象度が低い
  • エンジニアがカバーしないといけない責任範囲が広い
  • 過去を振り返って、未来に何が起こるかを考える
  • より高度に抽象化され、より高度に自動化される
  • 開発者がアプリケーションの開発に専念出来る
  • IaaS、CaaS、PaaS、FaaSにはそれぞれメリット・デメリットがある
  • 目的にあった最適なプラットフォームを選ぶ
  • 色々なものを組み合わせて使うという考え方も大事

コンテナ技術は抽象度が低いし、エンジニアの責任範囲が広いので、そりゃ疲れますよというお話。 コンテナ使うことが重要なわけではないし、きちんとビジネスの目的を達成する為の手段として有用なものを選択(組み合わせて使う)ことが大事ということでした。

総括

ほとんどのセッションは Kubernetes を中心としているお話でしたが、興味深いセッションが多くて楽しかったです。 こういった大きなイベントは体力を精神力を非常に持っていかれるのですが、新しい視点が増えたり、知らない技術の話とか、実際に使っている人の話が聞けてとても楽しかったです。 自分自身、まだまだKubernetesを理解出来ていない部分が多々あるので、地道に勉強をしつつ、いざ仕事で使い始める時にはちゃんとKubernetes自体を理解出来ている状態になっていたいと思いましたし、その為の準備を粛々と進めていこうと思いました。