初日についてはこちらをどうぞ。
builderscon tokyo 2018 一日目 - 誰かの役に立てばいいブログ
二日目は QUIC+TLS1.3 や Jepsen など楽しみにしていたセッションと、私も内容に関わったセッションなどに参加しました。
次世代通信プロトコルにおけるセキュリティ・プライバシー保護・パフォーマンス
@kazuho 氏による、TCP+TLS1.2 を置き換える QUIC+TLS1.3 の技術解説。
Kazuho's Weblog: 次世代プロトコル（QUIC etc.）のセキュリティとプライバシー @ #builderscon
QUIC+TLS1.3 は、TCP が提供する信頼性のあるストリームという抽象化による性能およびセキュリティ面での不都合に、真正面から取り組んで見直しています。 具体的には、
- src, dest の address, port の四つ組表現から離れ、IPアドレスが変更される環境でも維持される新たなコネクションの概念
- コネクションの確立に暗号処理を組み込むことでプライバシーを強力に保護
- パケット落ちに強い、多重化したストリーム
信頼性に欠けるパケットネットワークでやるならこうするべきだという主張が見えますね。本質をとらえた素晴らしい進化だと思います。
とはいえ TCP が提供していた信頼性のある単純ストリームは、その単純さゆえに多様なプロトコルを生み出してきたと思います。 QUIC+TLS1.3 はそこを覆すわけで、新たな生態系はここから皆で作り上げていく必要があります。 楽観的に言えばまだまだ遊びは続くってことで、新たなフィールドを切り拓いている kazuho 氏には心よりエールを送りたいと思います。
Jepsen 10
jepsen.io で分散データベース業界では知らぬ者のいない "Aphyr" 氏による講演。 詳しくない方に簡単に解説すると、MongoDB や Elasticsearch など、データを分散処理するクラスタデータベースの障害耐性を徹底的な実験で評価して報告し、様々な不具合を明らかにしてきた方です。
その影響力は絶大で、今や分散データベースを新たに作ると、Jepsen テストで評価するのがお約束になっている気がします。 レポート自体読み物として大変面白いので、analyses から一つ二つ読んでみることをお勧めします。
その氏いわく、「分散システムは実際に動作させて評価しなければダメだ」と。それをせずに、データの安全性を主張するソフトウェアは机上の空論にすぎないことを幾多と明らかにしてきたのですから、非常に重みのある言葉でした。
なぜエンジニアはパフォーマンス計測しないのか
タイトルは釣りで、身体の改善の話でした。
why_dont_you_measure_your_performance - Speaker Deck
スライドの末尾のほうにある
やる気を出すのではなく、 やる気が出る状態を作る
というのは非常に共感します。なにか作り出すとき、ひとまずドキュメントをコミットするのは私もよく行うやる気メソッドです。
業務時間で書いたパッチは誰のもの？ OSS 活動にまつわる罠
サイボウズの OSS ポリシーを作るにあたって著作権や商標についていろいろ学ぶ必要がありました。 この講演ではOSS活動をするにあたって考慮が必要な点を、当社の OSS ポリシーを織り交ぜながら解説しました。
私もこの講演に合わせて、会社のブログに解説記事を書いて公開しました。
OSSやフリーソフトウェアは、会社を越えてエンジニア同士が世界中で協力しあう文化をもたらしてくれました。 その原動力となった Stallman 氏や ESR 氏をはじめとする方々を強く尊敬しています。 私をエンジニアとして成長させてくれたもので一番大きいのは、間違いなくOSSとOSSコミュニティの方々です。
Building Self-Hosted Kubernetes
オンプレミスで k8s クラスタを構築・運用するのは大変なので、運用部分は k8s 自身にやらせるセルフホスティングをしようという内容です。
[ GitPitch ] nasa9084/slides/builderscon18
実は私もいままさにオンプレミスに Kubernetes クラスタを自動構築し、自動でメンテナンスしてくれる仕組みを作っています。 CKE といい、RKE (Rancher Kubernetes Engine) に影響を受けて宣言的なクラスタ構成を入力とし、自動的に宣言に合うようにクラスタを修正するのですが、RKE とは違って常駐サービスなので、故障時にも自律的に回復してくれます。まだ絶賛開発中です。
セルフホスティングには良い点もあれば、難しい点もあります。電源全落ちからの回復シナリオなどを考え、CKE ではセルフホスティングはしない方針にしました。 最も困難なところである、etcd (k8s クラスタの永続データを一手に引き受けてます)の自動管理は実装を終えています。
Extending Kubernetes with Custom Resources and Operator Frameworks
Kubernetes は組み込みリソースの Deployment などを管理するコントローラーに加え、独自のリソースを定義して管理する仕組みを追加できます。
CRD, Custom Resource Definition といいます。CRD は定義するだけなんですが、CRD を見て自律管理するコントローラーは自分で作る必要があります。
CRD を管理するコントローラーを operator と呼ぶのですが、わりと実装パターンが決まっているためフレームワークが出現しつつあるという内容です。
- operator framework: 元 CoreOS 社（現 Red Hat）製
- kubebuilder: Google 製
講演者が Google の方ということがあるかどうかわかりませんが、kubebuilder のほうが良くできているという感じで紹介されていました。
二日目は、個人的に思い入れが強いものが多くてエモい文章になってしまいました。 こんなに素晴らしい時間を作ってくれた builderscon の運営の方々には本当に感謝しています。
