CNDT2019 に参加してきました

Cloud Native Days Tokyo 2019に参加してきました。

きっかけ

もともとCloud Nativeに興味があり、Kubernetesなどちょこちょこ遊んでいたところに、この募集が流れてきました。

僕自身愛知の学生で、なかなか東京に来ることは出来ないためこういった支援制度があるのはとてもありがたいです。 採択していただきありがとうございます!

参加してみて

今回参加してみて、学生のうちに実際に働いてる人の話を聞いたり、セッションの聴講ができるというのは恵まれているなと思いました。

実際にセッションを聞いていて、手元で動かしているだけでは見つからないプロダクションならではの課題が聞けたり、チームでやっていくときに嵌りそうなポイントなど役に立つお話が聞けました。

面白かったセッション

いくつか抜粋して感想とメモを残します。

講中に残していたメモはDay1Day2です。

Opening

CNCF Cloud Native Definition v1.0

Cloud Native Trail Map

今回の来場者の46%が本番環境でKubernetesを運用しているという話を聞いて正直驚きました。

また、Stackanalyticsの紹介をされていました。 主に2016年に1社だった中国企業でが今では4社に増えているといった話や、CNCFのプロジェクトでは個人のコントリビュートが30%くらい占めている(!)という話をされていました。

Day 1ではOpenStack Upstream TrainingKubernetes Upstream Trainingがセッションと並行して行われており、そちらでは実際のプロジェクトにコントリビュートするためのトレーニングが行われていたようです。 そちらの資料は公開されるとのことで、公開が待ち遠しいです。

Performing Infrastructure Migrations at Scale

Airbnbの方による、どうやって新システムに移行するかという話でした。

技術的負債(Tech debt)が溜まっていくとつらいので新システムに移行するのですが、一気に移行はできないので新旧並行するタイミングは必ず存在します。そのタイミングはまた技術的負債になるのでつらいって感じでした。

*Migrations are the solver to systematically reduce tech debt** のワードが印象的で、結構胸に残ってます。

CircleCI 2.0を支える2つのコンテナクラスターとSRE

speakerdeck.com

技術編・組織編共にとても面白かったです。

中でも後半のSREチームの話はすごいなぁと聞いていました。

世界中に分散したSREチームが共同して障害対応を行うというのは想像もつかない苦労が裏にはあるのだろうと思いました。

メモ

技術編: 2つのクラスタ

  • Kubernetes
    • マイクロサービス用のコンテナ
      • 60くらい
        • フロントエンド
        • 課金
        • ユーザー管理
        • WebHook管理
  • Nomad
    • ビルド用のコンテナ
      • Docker imageのpull
      • コードのcheckout
      • ビルドコマンドの実行
      • Artifactsの保存 二つを分けることでセキュリティの担保
  • ユーザのコードをビルドする == ユーザのコードを実行できる

組織編: SRE

  • 分散したエンジニアリングチーム
    • アメリカ、ヨーロッパ、アジア
      • サンフランシスコのエンジニア単価がめちゃ高い
    • 今後は分散したエンジニアリングチームが主流になっていく?
  • ボーイング方式
    • Working together
    • 時差の有効活用
    • 継続的なペアリング
    • 無理のないアラート対応
    • 障害時対応
障害対応チーム構成
  • Incident Commander
    • Communication Commander
    • Incident Responce Team
    • Note Taker
  • ボランティアでできそうな人がやる
SRE Clinic
  • 週ごとにローテーションでToilを潰す
    • アカウントの削除、DNSレコードの追加 etc
  • Toil以外に集中できるようにする
  • Clinic
    • 駆け込み寺的なニュアンス
      pros, cons
  • Pros.
    • 他のエンジニアがタスクに集中できるようになった
    • 何がToilかの分類ができるようになった
  • Cons.
    • なにがClinicの仕事かの分類が曖昧
    • タスクからClinicへ映るときのタイミングが難しい
      • 自分のタスクを人に渡さないといけないので
    • Toil自体が減るわけではない

k3sで作る! 軽量k8sエッジコンピューティング環境

speakerdeck.com

Rancher Labsが開発した軽量なディストリビューションで、ARMアーキテクチャをサポートしていることからRaspberryPiで動くのが特徴らしいです。

実際にRaspberryPi3の上で動作させ、showKsならぬshow3sのデモを行っていました。

メモ

どうやってk8sから軽量化したのか

コードの削減

5つ機能を削った 1. レガシーまたは非デフォルトの機能 2. アルファ版の機能 3. クラウドプロバイダ向けのコード 4. Storageドライバ関連のコード 5. Docker(optional)

プロセスの削減

Kubernetesを構成する主要コンポーネントを単一プロセスにまとめた

showk3s

  • showKsの小プロジェクト
    • showKsと連携したk3sを用いたアプリケーション
  • k3sのエッジコンピューティングコンセプトをデモとして実装する

エッジコンピューティングで考えなければならないこと

  • 上流のネットワークは不安定
  • エッジ端末は壊れる
  • エッジは一般的に数が多い

Goldwing Smart Energy

Goldwing

  • スマート風力発電のために3万台を超える風車を運用

  • 各種データを数千箇所にあるエッジk8sクラスタに集約してアップロード

show3s

  • エッジコンピューティングについてきちんとした実装を素人がするのは大変
  • デモやPoC程度にはRPiとk3sの力で実現できる
  • お小遣い程度で公開できる
  • 興味あれば動かしてみて

おわりに

今回はスカラシップ枠での参加ということで、貴重な体験をさせていただくことが出来ました。

運営の皆様、本当にありがとうございます!

参加記録としてちょっと薄いものになってしまったのでこれから手を動かした記録などどんどんブログに残していこうと思います。

ありがとうございました!