CloudNative Days Tokyo 2019 1 日目参加レポート
CloudNative Days Tokyo 2019 1 日目に参加してきたのでそのレポートです。メモを文章化してリンクを貼るだけですがお許しください。資料が公開前で内容を照らし合わせていないので間違った記述があるかもしれません。
Keynote
朝は Keynote から始まりました。
Opening
オープニングは CloudNative とは何なのかという話から始まりました。定義の話から、こういうことをすれば CloudNative な開発といえるぞ、的な指標である Cloud Native Trail Map の紹介がありました。もう 1 年近く CloudNative 界隈にいるのですが、この Map は CloudNative を段階的に導入するのに参考にすると良さそうだなと思いました。
参加者アンケートにも触れていて、一番印象的だったのは (話でも出ていましたが) Kubernetes を本番導入している人が半数を超えていることでした。回答者の所属会社の内訳とかも知りたかったですね。本番導入していると答えた人の多くは Web 系企業かと思っていますがどうなんでしょう。参加者は 1,600 人 (回答者は 1,300 って書いてあったかな？記憶が曖昧) なので結構な人数ですね。
また、Stackalytics の統計にも触れていて、最近は OpenStack に対する 中国企業のコミットの勢いがすごいという話をしていました。先月 KubeCon China に参加したのですが、OpenStack に限らず中国だけで全部できちゃうんじゃないか、的な空気感がありました。CNCF 関連のコミットに関してはやはり Google がトップで 1/3 を占めておりましたが、個人的に驚いたのは同じように 1/3 が野良のコミットであるということでした。野良といっても企業の Organization に参加していないとかそういう分類だと思いますが数の暴力ってすごいなーと感じました。
ちなみに、Session と同時に OpenStack Upstream Training と Kubernetes Upstream Training も開催されるようでした。私は申込みをしていなかったので外からチラ見しましたが超良さそうな議論をしてました。次回あれば参加したいですね。こちらは後日資料が共有されるそうです。
? (Linux Foundation)
このパートは急遽話してもらったとのことだったのでタイムテーブルにタイトルが見当たりませんでした。
こちらは CNCF プロジェクトの話が主でした。個人的に Landscape に載っているやつは全部 CNCF プロジェクト のものだと勘違いしていたのでこの話が聞けてよかったです (笑)。プロジェクト配下のやつは枠で囲われてる 40 個くらいだけですね。 また、Apple が 6 月に CNCF のメンバー入りをしたそうでこの話も出ていました。Apple にそういうイメージはあまりなかったので意外ですね。
CNCF の Certification の話もしていました。現在 CKA の申し込みが 8,300、CKAD の申込みが 2,800 もあるそうです。申し込みの合計数なので全員がパスしているというわけではないです。CKAD は 2 月に取得したのが CKAD-1900-0443-0100 だったのですが、今はどのくらいの合格者になっているんですかね？
KubeCon + CNCon も参加者がめっちゃ増えているということも話してました。チケットすぐ売り切れるんだよなあ。あとホテルつらそう。
Collaboration Without Boundaries (OpenStack Foundation)
OpenStack Foundation の歴史を話してくれました。最初のグローバルカンファレンスが 2011, 2012 年あたりで、その時から NTT 来ててすげぇと話していた印象が強いです。
OpenStack を利用してる会社紹介では GMO が Ironic 使ってることとか話してましたね。どのサービスだろう。全部かな？
Performing Infrastructure Migrations at Scale (Airbnb)
Tech Debt (技術的負債) をどう解消して新システムへ移行していくかという話です。Tech Debt が溜まっていくと Efficiency が落ちていくので、それを解消 (回復) させるために新システムへ移行をします。移行するといっても全てを一気に移行することは当然できないので、依存関係を確認しながら粒度を細かくしていきます。そして簡単なものから徐々に移行していくわけですが、その際多くの場合は新旧システムが両方とも稼働することになります。そういう Mix System はまた Tech Debt を生むので同様につらみが生まれます。わかる。
そんなこんなで移行にあたって、Validation フェーズ (インフラコンポーネントの独立性の検証など)、Stress フェーズ (名称メモり忘れた。Low Latency/High Throughput でシステムに負荷をかけて変なこと起きないか見たりなど) を経てきたらしいです。現段階は、移行に時間がかからないようにサービスの設定を抽象化するようなレイヤを用意して、簡単に切り替えられるようにするフェーズにいる、まだできてないけどな、と話してました。その後も移行プロジェクト (?) のリーダーとの同意を取ったりする最終フェーズがあるらしいです。スライドの最後にめっちゃ良さそうなまとめが載っていたので、公開されたら見直したいですね。
ちなみに私は Airbnb を「エアーブンブ」と読んでました。正しくは「エアビーアンドビー」なんですね。
The 10 new rules of open source infrastructure (Canonical)
ここから Airbnb で集中力を持っていかれてちゃんと聞いてなかった気がします。「Upgrade をして Backport はするな」という言葉は心に残っています。新機能を使用したいなら Backport なんかせずにちゃんと Upgrade してね、そうしないと他の会社とは外れた手作りのインフラになってしまって負債になっちゃうからね、みたいな話だったと思います。確かにそういったミドルウェアに手を加えるのは極力やりたくないですね。(まあ Upgrade も大変ですけどね...)
また、インフラの Transition は必ず来るから Kubernetes で満足しないで次のやつにも身構えとけよ、というお話でした。
あと、途中で一瞬出てきた DeNA が Livepatch を使っているという話は結構気になりましたね。瞬断があるとは聞いたことがありますが、どのくらいのワークロードのマシンまでなら Livepatch できるのか知りたいです。
Demand Less Choices! (IBM)
Knative の話です。1 コマンドで Autoscale するアプリケーションがデプロイされるのを見て Knative をやりたい気持ちが高まりました。前に触ったときにアプリケーションを放置してると Pod が 0 になって久しぶりのリクエストに時間がかかるみたいなことがあったのですが、あれって結局設定とかで制御できるんですかね？次は時間を使ってじっくり触ってみたいですね。
Session
セッションのメモです。
Kubernetes クラスタのポータビリティを保つための 8 原則
Wantedly の方のセッション。ランチセッションだったのでマイセンのカツサンドを食べながら聞きました。内容はタイトル通り。Wantedly は古くから Kubernetes を使っているようで、古いクラスタの etcd のメジャーバージョンアップデートをしようとしたらしいのですが、リスクが大きいと判断してクラスタを作り直すことにしたそうです。そのときの運用で直面した問題からこの原則が生み出されたようです。
8 原則のうち 5 つは The Twelve-Factor App のいくつかをベースにしており、新しい原則として非名前管理、バックアップ、重複欠損管理の 3 つを挙げていました。「非名前管理」は Kubernetes クラスタが用意してくれる DNS レコードに意味を持たせず、label に依存したり、CNAME で抽象化させたりする、というものです。それを強制させるためにわざとクラスタ名に日付など依存できないような文字列を入れているのは賢いなと思いました。「バックアップ」は移行後のアプリケーションのデプロイを簡単にさせるために heptio/velero (Heptio Ark から名前変わったんですね) でリソースのバックアップを取る、というものです。これはデプロイを実際に行うアプリケーションエンジニアへの配慮ですね。「重複欠損管理」は移行時のアプリケーションの扱いについて、重複して起動して良いものなのか・ダメなもの (つまり欠損を許容しないといけない) なのかどちらを守るかのポリシーを決める、というものです。これについては Multi-Cluster Strategy というものを定義して at-least-one ならそのリソースを Create してから Delete する (重複タイミングが存在する) ようにして、at-most-one ならその逆で Delete してから Create する (欠損タイミングが存在する) ようにして、このように移行時の扱いを決めているようです。このパラメータは label とか annotation で定義してるのかな？とにかくこういう移行ポリシーを決めてるのは良いなと思いました。
The Twelve-Factor App をベースにしている部分もインフラにフォーカスして説明されていたのでとても飲み込みやすく、共感する部分も多かったです。アプリケーションエンジニア側とインフラエンジニア側の責任の区別 (?) みたいなのがしっかりされていて動きやすそうだなと感じました。こちらはもう資料が上がっていますね。
Kubernetes クラスタの自動管理システムのつくりかた
Cybozu の方のセッション。Neco プロジェクトにおける CKE (Cybozu Container Engine) のアーキテクチャの話です。もともと Rancher を使おうとしていたらしいのですが、コンテナランタイムに containerd がどうしても使いたくて CKE を自作するに至ったようです。
アーキテクチャ的には中央集権となる CKE Manager 的なクラスタが 1 台いて、そいつが Kubernetes Master/Node をプロビジョニングするというものでした。Manager となるクラスタが設定を Declarative に管理しているので Auto Repair 機能や Node の入れ替えとかがとてもしやすそうだと感じました。またそのクラスタで Vault を動かしており、そこで証明書の発行や Secret の暗号化を行っているようでした。以前 Kubernetes クラスタ (Master HA 構成) で Secret の暗号化を oracle/kubernetes-vault-kms-plugin でやったことがあるのですが、同クラスタ上で Vault や Consul のクラスタを組んだりと面倒だったので、中央集権 Vault がいるとかなりやりやすそうですね。
あと、Master HA 構成時の kube-apiserver の前段 LB が信頼性担保などの面で用意できなかったようで、そこは rivers という自作のリバースプロキシ (川かな？と思ったけどダジャレで笑った) を用意したとのことでした。それを Kubernetes Node に展開して kubelet のリクエストをハンドリングすることで対処しているようです。記憶があいまいですが、kubelet が etcd へのリクエストに失敗したときに他の etcd ノードに聞きに行ってくれない問題の workaround としても機能しているそうです。
CKE のソースは公開されている ので時間あるときに読んでみたいですね。OS のインストールどうしてるのかとか、外部向けの type Loadbalancer 作りたいときにどうするのかとか色々気になります。
Kubernetes 拡張を利用した自作 Autoscaler で実現するストレスフリーな運用の世界／adtech studio における CRD 〜抽象化した GPUaaS による段階移行計画 & AKE Ingress v2〜
CyberAgent の方のセッション。20 分 / 20 分の 2 人のセッションでした。
自作 Autoscaler の方は、運用しているアプリケーションが Cloud Pub/Sub の Subscriber (Kubernetes Pod) とそれからのリクエストを処理する Bigtable の 2 箇所にボトルネックがあってそれをいい感じにオートスケールさせようというものでした。Bigtable の負荷状況は Stackdriver Monitoring から取得しており、スパイク判定はめっちゃいい感じに調整された (ウィンドウサイズなど) 移動平均を用いているようでした。オートスケールの管理は CRD + Custom Controller でやっているとのことでしたが、その Custom Controller に kubebuilder とかを使わないでフルスクラッチで実装したというのが驚きでした。。。
GPUaaS の方は、ML 系のエンジニアのために GPU リソースを管理できる CRD + Custom Controller を作ったという話でした。普通に Deployment とかでも実装できるようですが、キャッシュ機能などをつけるとなると Custom Controller じゃないと実現できないとのことでした。nvidia-docker を用いて GPU のリソースを分割して提供しているそうです。Datadog のダッシュボードも映してくれたのですが、ちゃんと誰がどのくらい使ったかが表示されていて良さそうでした。現段階では ChatOps のレベルまで落とし込んでいてこれから更に使いやすく調整をするようでした。ML 側のエンジニアの温度感はあまりわかりませんが、Kubernetes があまり流行っていない領域だと思うので頑張って布教してほしいですね。
こんな感じでこのセッションは CRD がメインのセッションでした。ちなみにセッションの最後にブースで Kubernetes キーキャップを配っているというアナウンスがあってブースの通路が通れないくらい激混みになっていました (笑)。
GPUaaS の方は資料上がってます。
Operator でどう変わる？これからのデータベース運用
こちらも CyberAgent の方のセッション。Operator 入門者向けの内容だったので、Operator って何？CRD とか Custom Controller って何？という人は資料に目を通しておくと良いです。説明はかなり丁寧でわかりやすかったです。
OperatorHub.io という Operator まとめサイト的なものがあるというのを知ることができたのは良かったです。Awesome Operators のちゃんとした版って感じですね (失礼)。
資料上がってますね。
OCIv2？！軽量高速なイケてる次世代イメージ仕様の最新動向を抑えよう！
NTT の方のセッション。OCIv2 (正式な名称ではないらしい) が策定中のようで、そこで議論されている今後策定されるかもしれない内容についての話。
OCI はコンテナに関する標準化をしている団体ですが、今 3 つの標準化プロジェクト、image-spec、runtime-spec、distribution-spec (これは OCI 公式にリンクがなかったんだけどただの見落としだろうか？) があります。distribution-spec だけイメージが湧きづらいと思いますが、これはコンテナレジストリなどが対象になったプロジェクトです。
メインテーマは image-spec ということで最初にコンテナイメージの tarball 内の構造について説明があり、その後デモがありました。構造は Markle Tree (つまりハッシュツリー) になっており、内部のメタデータが /index.json で管理されています。その json ファイルに manifest というイメージの構造を表す Key/Value があり、そこからベースイメージやその各レイヤーイメージを追うことができます。デモではその情報をもとに Container Registry の API を curl で叩いていました。Container Registry は主に 3 つのデータを必要としていて、そのコンテナイメージが持つレイヤーイメージの tarball (中に root file system が入ってる) と、Container を実行する際に適用する実行時情報 (これの実体は確認してないので暇な時に見たい) と、その 2 つを紐付けるための manifest (どのファイルを指してたっけな...) を渡すことによって初めて docker push と同様のことが実現できます。逆にその送り先の URL から manifest を GET することによって、どのイメージがどの実行時情報に紐付いているのかという情報が得られます。このようにして docker pull 相当のことができます。その後は runc run コマンドを直接たたいてコンテナを実行するところまでやってもらいました。とても面白そうだったのでこれ書き終えたら手元で試そうと思います。
...と書きましたがデモは前座で、本題はコンテナイメージのレイヤーの重複排除が効きづらいから新しい OCIv2 を策定中だぞという話でした。実際に有名なイメージのレイヤーがどのくらい共通して使われているかという統計を示されていたのですが、レイヤーの 8 割くらいはユニークなレイヤーでした。つらそう。重複排除は当然 1-bit でも異なれば別のものとみなします。ですがそれはレイヤーレベルの話なので、もっとファイルレベル、ブロックレベルなどに落とし込んで重複排除が効くようにしようという話が進んでいるそうです。また、tar 自体にも問題があり、実装依存で index がずれたりするので重複排除が効かなくなるケースや、仕組み上うえから順に取り出す (シークができない) ので並列処理ができないことなどがあり、もしかしたら将来的に違うツールを使うことになるのかもしれませんね。
余談で Lazypull と呼ばれる、ファイルにアクセスがあった時点でネットワーク越しにイメージレイヤを取ってくるドラフトの話や、distribution-spec の領域で OCI Artifact Registry と呼ばれる Docker、Kubernetes、Helm などのリポジトリを統合して使えるようにしようという動きも進められているそうです。これに関してはすでに oras といった実装があるそうな。
とても Deep で面白いセッションでした。
失敗しない! Kubernetes 向けストレージ選び 5 つのポイント
Z Lab の方のセッション。Kubernetes でストレージを使うときにどういうことを考慮して選択しないといけないのかという話。序盤に話してた MySQL Operator 的なものを自作していた話が強烈でしたが、それについての詳細は著書のKubernetes 実践入門に載ってるそうなので買いましょう (私も読みました)。あと、ここも Cybozu や CyberAgent と同じように Kubernetese as a Service を作っており、タイプとしては Cybozu の CKE と同じ中央集権タイプでした。管理側の Kubernetes が OpenStack を叩いてデプロイしている感じです。Kubernetes クラスタを CRD で管理しているのが先進的だなと思いました。
本題のストレージの考慮ポイントは下記にまとめます。
- Rolling Update
- Rolling Update に限らずストレージを要求する Pod がたくさん立つ状況が Kubernetes では存在するので、そのボリュームの Attach/Detach リクエストが大量に飛んできても耐えられるものを選択する。Kubernetes は RESTful API でストレージをリクエストするのでボリューム払い出す側がそのリクエストをさばけるようでないといけない。複数 Node でマルチパスが張れるならなお良い。
- Locking
- Security
- Quota
- Kubernetes の Quota は Napespace 単位の管理しかしないので、複数クラスタのときはストレージ側の機能も使って合わせ技でいい感じにする。
- Value
- データの価値を考える。Storage Class に Gold (アプライアンス製品) / Silver (Ceph とかの SDS) / Bronze (ROOK とかの Container-Native Storage) みたいなランク付けをして、価値に応じて置き場所を決定する。保険と同じだから消えたらやばいやつはちゃんと金払って良いところに置いてやれ、という話をしていてなるほどとなった。この 3 つの比較をする表が良かったので公開されたら見てください。あと Ceph って壊れたら多分直せないよね...という話を聞いてゾッとした。
最後に、「VM が出た頃はステートフルな物を置くのをめっちゃ嫌ってたのに、今は普通にステートフル乗せてるし、コンテナもいずれそうなるかもね。」という感じの話をされていてとても心に滲みました。
1 日目全体の所感
セッションは面白いものが多く、どれもハズレがないなあという印象でした。会場全体としてはちょっと小さくてセッション待ちや、スポンサーブースを回るのがちょっとキツかったですが、セッション会場内は適切な大きさでそんなにストレスはなかったです。お昼はランチセッションを考慮した食べやすいマイセンのカツサンドだったのでとても満足でした。運営の方々ありがとうございました！
ブースでは Oisix さんから Vegeel という 2 日分の野菜が摂れるという神飲料をいただきました。家で冷やして飲みましたがめちゃくちゃおいしかったです。濃い野菜ジュースみたいな感じでした。私は最低週 2 回サラダを食べるようにしているので、これで今週分は達成したということになります。ありがとうございます。
Wi-Fi については提供スポンサーがいるわけではなくて虎ノ門ヒルズのものなので仕方ないと思うのですが、朝あまりにも繋がらなくて以降キャリアの回線を使っていました (その後繋がりやすくなったかもしれませんね)。あそこの Wi-Fi は 2.4Ghz っぽかったのでテザリングは控えて、スマホでぽちぽちメモを取っていました。
とりあえず、明日の夜は手を動かす系のやつの検証をしたいです (私のメモがミスっている可能性があるので)。
2 日目は疲れてなかったら書きます。
