Japan Container Days v18.12 参加メモ
JapanContainerDays v18.12に参加してきたので簡単な参加メモです。
reannkara.hatenablog.comに引き続き今年で2回目の開催で、しかもセッション期間は2日間という盛りだくさんのカンファレンスでした。参加したセッションは結構あるのですが、特に印象に残った部分をメモっておきます。
Microservices Platform on Kubernetes at Mercari
Keynoteの中でメルカリさんの@deeeetさんのセッション。 なぜメルカリはコンテナとKubernetesを採用したかについて説明されていました。
メルカリさんと言えばモノリシックなアプリケーションからマイクロサービスへの移行を非常に謳っており、安心してサービスをリリース出来る環境を構築することが重要であると認識しているとのこと。
コンテナを利用することでアプリケーションの実行環境が不変であることが担保でき、リリース時に何か不具合があれば安全にロールバックでき、またカナリアリリースもすることができると。
また、Kubernetes自体が高い拡張性を持っており、他のPaaSといったサービスでは実現できない共通プラットフォームを独自で構築できるのではないか、また、周辺エコシステムの成長やいざとなれば自分たちで拡張できることも採用した要因だと仰っていて、非常に目的がハッキリしていると感じました。
何のためにその技術を採用するのか、自分たちも何か技術選定をする際にはちゃんと目的意識を持って採用しなければならないなと痛感しました。
Kubernetes がもたらす 分散システムの脅威との戦い
Wantedlyの@koudaiiiさんのセッション。 全てのプロダクトをKubernetesへ移行したことにより恩恵を受けたが、同時に発生した課題に対してどのように対処してきたか、どのように対処していこうかというセッションでした。
Kubernetesを扱う事自体が複雑なシステムを取り扱うことになりますが、その中でもシンプルさを追求することを諦めないという考え方に非常に共感を得ました。周辺エコシステムの成長が非常に活発であり、魅力的なツールも増えてきていますが自分たちに本当に必要な技術のみを採用するという考え方はわかっていてもなかなか実践できないよなぁと最近痛感しています。 このへんの考え方は最近開催されたKubeConで話されたJulia Evansさんの "ignore most kubernetes ecosystem software" に通じる考え方なのかなとも今振り返って思いました。
他にもKubernetesを導入したことでマイクロサービス化が推し進められたが、マイクロサービスを導入したことにより発生した課題だったり、Kubernetesという複雑な分散システムを扱うことの難しさについて正面から向き合っており、これから多くの企業が直面する課題について説明されていたのではないかと思います。
恐らく自社でも形を変えて直面するであろう課題ばかりで本当に参考になるセッションでした。
Kubernetesが超強力な分散RDBに vitessの真価を大検証してみた
YouTube発祥のOSSであるVitessについてのセッションでした。 VitessとはシャーディングによるMySQLの水平スケーリングのためのクラスタリングシステムであり、Kubernetesに依存しないシステムであること（CNCFにはインキュベートされているみたい）。
アーキテクチャが面白いなと感じて、アプリケーションとMySQLの間にリクエストをプロキシするVTgateというプロセスを配置して、どのMySQLにクエリを発行するべきかなどのメタデータはTopologyというメタデータストアに保管、クエリは各MySQLノード上で稼働するVTtabletというプロキシデーモンが受け付けるという構成となっているみたいです。
私はMySQLを扱ったことはないのですが、これを利用すればアプリケーション側からはどこにデータが存在するのか意識せずに透過的にデータへとアクセスできるのではないでしょうか。本番運用に耐えられるかどうかは検証がもちろん必須ですが、こういった抽象化層を一段設けることによってアプリケーション側の実装負荷を減らすといったアプローチは非常に面白いと感じました。
コードを書くことに集中したい全てのアプリ開発者に贈るKubernetesの話
コンテナ環境で稼働するアプリケーションを実装する際の考慮事項に関するセッションでした。 デプロイ環境の際による設定の保持方法や、ロギング、サービスメッシュ、開発ツールなど、正直、ロギングやサービスメッシュといった分野はアプリケーション開発者に意識させたくない領域だと思っているので、全てのアプリ開発者が知っているべきかと言われると組織に寄るなとは思いました。
ただ、アプリケーションの設定の保持方法については非常に参考になりました。
非コンテナ環境でアプリケーションの設定をする場合には、設定ファイルを各デプロイ環境ごとに保持しており、アプリケーションのビルド時にどの設定ファイルを利用するかを決めていました。こうしてしまうとアプリケーションのリポジトリに同じような設定ファイルを複数保持することになり、保守性が下がってしまうなと感じていました。
同様に、全ての設定内容を環境変数に定義することもしんどいだろうなとも感じており、今までの形式通りファイルで設定を持ちつつも保持する設定ファイルを減らしたいという思いがありました。
セッション中で話されていた、envsubstを利用すればテンプレートファイルは保持しつつも、環境毎に異なる部分だけを差し替えることができるので上記で感じていた課題を解決できるのではないかと思います。
runcだけじゃないコンテナlow level runtime徹底比較
speakerdeck.com speakerdeck.com
前回のContainer Daysで話されていた内容の続きとなるLow Level Runtimeに関するセッションでした。 私自信、コンテナの実行環境を意識するようになったのはKubernetes上でのトラブルが発生した時で、kubeletからDockerコンテナが稼働するまでの一連のプロセスを調べた時に初めてOCIやCRI、runcといったものを知りました。
Low Level Runtimeといっても本当にたくさんあることを本セッションで初めて知り非常に面白かったです。
GitOpsではじめるKubernetes CI/CD Pipeline
www.slideshare.net
GitOpsについては言葉だけは知っていたのですが、実際にどういったものかは知らなかったので非常に参考になりました。 CIツールを中心に据えたデプロイフローをCIOpsと呼び、それに対して、CIとCDを分離し、コンテナイメージのビルドまではCIツールが行い、デプロイはCDツールで行うというのがGitOpsとなります。
実際のリリースフローに関しては各組織によって文化や考え方が異なるので全てがGitOpsであるべきとは言えないとは思うのですが、一つの考え方としてもう少し詳細に調べておきたいなと思いました。
Introducion to CRIU
ペパボの@udzuraさんのCRIUとその応用例に関するセッションでした。
CRIUとはLinux向けに開発された、アプリケーションプロセスのチェックポイント・リストア機能を提供するツールでDockerでも利用されているツールです。実行されていたプロセスのその時の断面を取得することが出来るので、アプリケーションの停止・再起動時の起動時間を短縮することができたりします。
この機能を利用して@udzuraさんは、Haconiwaという独自のコンテナランタイムを開発されており、元ペパボ（現さくらインターネット研究所）の@matsumotoryさんが提唱したFastContainerアーキテクチャ（実際のプロダクトだとロリポップ！かな）でも実際に組み込まれているそうです。
ホスティング事業者が抱える課題を解決するためにアーキテクチャから考え実際に実装し、それを外部へと発信していくという行為自体が只々凄いなと改めて実感しました。
HaconiwaやFastContainerに関する記事はたくさんあると思いますが、自分が見つけたものを貼っておきます。
最後に
あまりこの記事の中では書きませんでしたが、今後Cloud Nativeという言葉がますます認知されていく流れなのかなとなんとなく感じました。 来年からContainer Daysという名前からCloudNative Daysという名前に変わることからもなんですが、今後の関心事がDockerやKubernetesといった今まで中心的な位置に存在していたプロダクトから、それを取り巻く周辺エコシステムに推移していくのではないかという単なる直感です。
それはDockerやKubernetesが廃れるということではなく（もちろんより良いプロダクトが生まれれば廃れるとは思いますが）、それらのプロダクトの存在が当たり前となったときに、今までアプリケーションレイヤーで自前で実装していたものが、周辺エコシステムの発展によって不要になり、より純粋なアプリケーションコード（ビジネス領域に特化したアプリケーション）の実装に向かっていくのではないかという個人的な思いつきです。その現れがIstioといったサービスメッシュではないかと。 それと同時に構成されるシステムはますます複雑になっていくのではないかとも個人的には思っています。
実際にどうなっていくかはわかりませんが、様々な技術が生まれた時に適切な技術を選ぶ、または自前実装できる技術力を持つというのは変わらないと思いますのでこれからも手を動かしながら楽しんでやっていきたいなと思いました。
最後に、このような素晴らしいカンファレンスを開催していただいた関係者の皆様には本当に感謝しかありません。
ありがとうございました！！
