Japan Container Days v18.12 参加レポート

f:id:yu_suke1994:20181205140614j:plain

12月3日から5日にかけて、Japan Container Days v18.12が開催されました。弊社からは、業務扱いで id:yu_suke1994 と id:fujikawa-y の2名が参加しました。今回はその参加レポートになります。

多くのセッションに参加しましたが、その全てに言及するととんでもなく長い記事になってしまいそうなので、印象深かったセッションに絞って感想を書いていこうと思います。

keynote

keynoteでは、複数の企業におけるKubernetesの役割などについて話されました。

CNCFのChris Aniszczyk氏からは、CNCFの目指す地点、今後のロードマップなどについての話がありました。Serverlessだけではなく、Nodelessへの流れ、KubernetesをIoTやedge computingの世界まで広げたいという野望、kubeletそのものを仮想化するvirtual-kubeletの紹介などがありました。

github.com

またCNCFで定義している各プロジェクトの成熟度合いも確認することができるようです。

Projects - Cloud Native Computing Foundation

1年間の本番運用でわかったコンテナがチーム開発にもたらしてくれたもの

本番環境でコンテナを使うという事例を話されていました。

そもそもなぜコンテナ化をするのか？というところから言及されており

開発環境を快適にしたい
開発環境と本番の乖離をなくしてサイクルを早くしたい

これに尽きるのは納得の行く話でした。

そして、途中で口頭であった 心理的安全性を保つためにコンテナ化 というのが印象深かったです。

40 topic of Kubernetes in 40 minutes

Japan Container Day 2018 from Yoshio Terada

マイクロソフトの寺田さんによる、40分でKubernetesにおけるトピックを40紹介する、という駆け足の発表では、 $ kubectl explain というコマンドの存在に衝撃を受けました。今までは https://kubernetes.io/docs/reference/#api-reference を見ながらYAMLを書いていたのですが、このコマンドがあればわざわざブラウザを使わずともYAMLにどのようなリソースの定義を記述できるのかがわかるので便利だと思いました。

1人でできるDocker/Kubernetes(GKE)を使った新規サービス立ち上げ

DeNAの新規サービス立ち上げにDocker/Kubernetesを使われた話が聞けるということで聞きに行きました。

最初からRailsで行くことのとチャレンジングなところでコンテナを使うという話があり少人数でサービスを作るノウハウと過去の開発で課題だったことが印象深かったです。

また、サーバー側とインフラ側で担うところも明示的に示しておりとても参考となりました。

2020年のコンテナはどうなる!? コンテナプラットフォームのこれまでとこれから

コンテナ界隈の人たちを呼びこれからどうなっていくかを話されていまいした。いくつかの議題があり、それに対するコメントのうち印象に残ったものを抜粋して記載します。

コンテナ技術浸透した？
- 浸透したと思う理由
  - 来場者のアンケート回答結果の9割が使っているというのがあり、自分で調べられる状況にある
  - 普及はしているが、本番はこれからという印象
- コンシューマ向けサービスの開発はβ版でも使っている
  - 開発、CICDもやっているが本番はやはりまだ少ない
- 浸透したと思えない理由
  - 詳しい人とまったく詳しくない人の二極化が目立っている
  - 使えるけど、メリットに繋げられない人も多く感じている
  - エンタープライズには話が通じないのが現状
  - さらに概念を理解せずに使っている印象がある
- どこがネック？
  - コンテナをコンテナらしく使うことが今後の課題
  - コンテナを使うからこその付加価値が必要
- コンテナは何が動くのか？ということもありまた、マイクロサービスの定義にも繋がってくる
  - マイクロサービスは組織の問題も関わってくる
  - アプリケーションレイヤーのI/Fだけ連携する
    - その中の話はチームに権限委譲して自律的にやってもらうのが良い
- システムを組織に合わせるのが今の日本の組織。
- Webサービスなら導入できるが、エンタープライズはハードルが高く慎重である
- 本番導入済のところはマネージドサービス使われているのが前提であって、自前で動かしている人は考えることが多すぎて本番に導入できないのではないか？というところがある
k8sがデファクトスタンダードになっているが差別化は？
- k8sの導入、運用、カスタムができるという差別化となる
- k8sの全部の機能いります？という疑問に行き着くところもあり、他のやつを使った方が良い場合もある
- 更に言うとコンテナ使えるだけいいのでは？ということも言える
- Runcherもk8sとの差別化を意識しつつ使う人が幸せになるようにしたい
- k8sの良さは拡張性があること
- k8sのデプロイとバージョンアップが大変
  - また初期の学習コストが高くアプリデベロッパーへどう浸透させていくのか？が課題。
今後追うべき技術は？
- Knative
- サービスメッシュが来る。Istioがきて成熟期になる
- イベント情報をキャッチアップすることが大事
- CoreOSも追うべきもので、それも含めて運用を楽にするためのもの
- AIのKubeflowでデータパイプラインが必須な部分なのでこれも追う

Cloud Nativeプロダクト1000本ノック

CNCF Landscapeには、CNCFでないプロダクトも含め、600を超えるプロダクトが掲載されています。

landscape.cncf.io

このセッションでは、データストア、CI/CDなどのトピックに分けて主要なCNCFプロダクトの紹介が行なわれました。辛うじて名前だけ聞いたことがあったりするものや、初耳なプロダクトも結構あって、こんなの追い切れないだろう……と思いました。だからこそ、コミュニティとして活動し、様々な検証を持ちよって情報を共有し合うことが重要になるのですね。

また、Cloud Native Trail Mapを見るとわかるのですが、コンテナ化、Kubernetesによるオーケストレーションは "Cloud Native" という観点ではまだ入口に過ぎず、そこで満足していてはいけないのだなということも感じされられます。(プロダクトの規模にもよるとは思いますが……)

また、このセッションで知ったのですが、Spinnakerがpipelineをコードで管理できるようになっていたのには驚きました。それまではGUIによるpipeline定義しかできず、.circleci/config.yml のようにコード化できないのはちょっと、なーと思っていたところなので、導入に向けて前向きになれますね。

blog.spinnaker.io

pipelineの定義については、イベントでデモとして提供されていたshowKs( https://showks.containerdays.jp/ )で実際に使用されているものがGitHubで公開されています。

github.com

runcだけじゃないコンテナlow level runtime徹底比較

皆さんはコンテナのruntimeを意識してDockerを使っていますか？僕は全く意識していません。

Dockerは、コンテナのruntimeとして、デフォルトでruncというものを使用します。このruntimeは実は様々な特性のあるものが公開されているのですが、よっぽどのことがない限りはruncから変更することはないでしょう。

このセッションでは、そんな様々なruntimeの紹介と、それに対してのベンチマークを行い、その結果や選択の指針についての発表が行われました。紹介されるruntimeはどれも特色にあふれ、技術的好奇心を刺激されはするのですが、じゃあproduction環境で使いますか、となるとそこまでのメリットは感じられない、と言うか一般的なユースケースにおいてrunc以外をあえて使うことって無いよな……と感じました。Nabla containersとか、うおお何じゃそれ！とはなるんですけどね……

とある30秒でできるKubernetes + GPU 開発環境

Canonicalの方による、 https://microk8s.io/ の紹介LTがありました。microk8sは初耳でしたがsnap packageになっており、Ubuntuユーザーの僕としては何ならMinikubeより導入が楽なのでは？という気さえしました。会場にいた方のなかには、「Minikubeはなにやってるかわからなくて若干ブラックボックス感があるのでmicrok8sのほうが好きだ」と言う意見もあり、ローカルでもKubernetesで開発する際にはぜひ使ってみたいと思いました。

CRIUの概要とその活用 - 未来のコンテナ技術について

GMOペパボにて、mrubyによるコンテナランタイムhaconiwaを開発していらしゃるうづらさんの発表でした。今回はhaconiwaの話ではなく、CRIUの話でした。

皆さん、 $ docker checkpoint というコマンドをご存知でしたか？僕はこの発表で初めて知りました。CRIUは、checkpoint/restore という機能を実現するためのツールです。利用することで、あるプロセスのその時点でのsnapshotを取得でき、その情報からプロセスの状態を復元することができる、ということが可能になります。

デモでは、whileループでカウントアップしていく変数の状態が、$ docker checkpoin crerate → $ docker start --checkpoint の前後で保持されていることが確認できました。

docker v18以降では、checkpointはうまく動かないようですが、これが安定して動作するのであれば夢が広がりますね。例えば規模の大きなRailsアプリケーションは、起動に若干の時間がかかり、突発的なスケールには対応できません。これが、起動後の状態のcheckpointを作成しておき、それを展開することによって素早いスケールアウトができるようになったりするでしょう。

Runtime BoF

docs.google.com

ディスカッション形式でruntimeについて話すTechMeetingでは、第一線で活躍しているエンジニアの方々による、runtimeに限らない様々な議論について聞くことができました。先程も書きましたが、結局runtimeをruncでないものにするメリットってあるんだっけ、という話から、コンテナイメージのセキュリティの担保、はたまた海外でのカンファレンスやOSS開発における英語問題など、本当に議題は様々でした。

コンテナイメージのセキュリティに関しては、とても考えさせられました。Docker Hubで個人が公開しているimageは使用しないというのは前提として、企業が公開しているimageであっても、それに悪意のあるコードが混入していないという保証はありません。imageに署名をするよりは、継続的なimageのスキャンのほうが重要である、という意見がありました。CNCFにも、そのようなことを行なってくれるClairというものがあります。またGCPにも、Container Analysisという機能があります。積極的に使っていきたいですね。

感想

非常に濃いイベントでした。便利そうなCloudNative productの情報であったり、Kubernetes運用の知見であったり、他の企業がどうしているのか、今後のCloudNativeの方向性、などなど……情報量で圧倒されました。今年は、聞くことのできなかったセッションのスライドを読んだりして、内容を噛みしめたり、書籍を読んだりして、今後のサービス開発に役立てられることがないか考えることにしようかと思います。

また、今年2回目となるJapan Container Daysですが、今回で最後となることが発表されています。ですが、CloudNative Daysと名前を変え、来年には東京だけでなく福岡や大阪でも開催されることが同時に発表されました。しかも福岡開催はRubyKaigi2019の直前ということで、僕は個人的にめちゃくちゃ盛り上がっています。

https://cloudnativedays.jp/

CloudNative、やっていきましょう。