2023年6月13日、ニューヨークのブルックリンにあるNew York Marriott at the Brooklyn Bridgeで、第9回QCon New Yorkカンファレンスの1日目が開催された。この3日間のイベントは、エンタープライズ開発コミュニティにおける偏りのないコンテンツと情報に焦点を当てたソフトウェアメディア会社であり、InfoQとQConのクリエーターであるC4Mediaが主催するものである。Radia Perlman氏による基調講演と、以下の4つのトラックからのプレゼンテーションが行われた。
-
- NetflixのエンジニアリングディレクターであるSergey Fedorov氏がホストを務めた。
- 世界で最も成功しているテクノロジー企業の舞台裏を紹介した。
-
- DoorDashのシニアスタッフエンジニアであるAllen Wang氏がホストを務めた。
- シンプルかつ効率的でスケーラブルなデータアーキテクチャを構築するために活用できる、基本的で強力かつ汎用性の高いビルディングブロックとそのコアとなるエンジニアリング原則を学べる。
-
- Chainguard社ソフトウェアエンジニアのPriya Wadhwa氏とScott Logic社CTOのColin Eberhardt氏がホストを務めた。
- 言語プラットフォームの最新動向を紹介し、開発者が多様なプラットフォームで多様な言語を使用してコードを記述できるようにする。
-
Staff+エンジニアリング：新しいスキル、新しいチャレンジ
- コムキャストのエンジニアリングフェロー、 Leslie Chapman氏がホストを務めた。
- このトラックでは、Staff+ Engineerとして効果的に成功するために必要なことが語られる。
また、スポンサード・ソリューション・トラックも1つ用意された。
C4Mediaの社長であるDio Synodinos氏、C4Mediaのプロジェクトマネージャー兼ダイバーシティリーダーであるPia von Beren氏、C4MediaのコンテンツプロダクトマネージャーのDanny Latimer氏が開会の挨拶を行い、カンファレンスの詳細を紹介した。初日は前述のトラックリードが自己紹介を行い、それぞれのトラックでのプレゼンテーションについて説明した。
基調講演概要 "アイデンティティ "のさまざまな側面
ネットワークデザインの先駆者であり、スパニングツリープロトコルの発明者であり、Dell TechnologiesのフェローであるRadia Perlman氏は、「The Many Facets of "Identity"」と題する基調講演を行った。Perlman氏は、認証方法の歴史に基づき、「アイデンティティの問題」という言葉がいかに理解されていないかについて、非常に鋭い考察を行った。彼女は「ほとんどの人が『アイデンティティ』の定義を知っていると思っている...ようなものだ」と主張した。
Perlman氏はさらに、「ID」のさまざまな側面について説明し、これには、人間とDNSの命名、人間やDNSの名前の所有権を証明する方法、ウェブサイトを適切に認証するためにブラウザが知る必要のあるものなどが含まれるとした。DNSの理論は、彼女が説明するように「美しい」のだが、現実には、ブラウザで検索すると、一般に不明瞭なURL文字列が返ってくる。そのため、Perlman氏は運転免許証を返そうとしたところ、詐欺の被害に遭ったことがあるという。
続いて、人間がパスワードのルールを正しく守ることが難しいこと、セキュリティクエスチョンの実現性に疑問を呈し、IDプロバイダーを利用することを推奨した。Perlman氏は、公開鍵基盤（PKI）を「何年経ってもクレイジー」と評し、「この名前はこの公開鍵を持っている」というメッセージに署名する装置である認証局を、DNS名を返すレジストリに関連付けるべきと論じた。
そして、インターネットプロトコルがX.500名ではなくDNS名を使うなど、X.509証明書の問題点を説明した。「特定のIPアドレスで受信できることが安全であるならば、このような派手な暗号は必要ない」とPerlman氏は述べた。次に、DNSの階層型名前空間（名前空間の各ノードが認証局を表す）を使って、トップダウン型とボトムアップ型のモデルを比較した。
Perlman氏は、1988年頃にCharlie Kaufman氏が考案したボトムアップモデルを推奨し、その理由は、組織が認証にお金を払う必要がないからだという。また、トップダウンモデルでは、ルートレベルでの独占が続き、ルートはどんな人にでもなりすますことができてしまう。
Perlman氏は、名前は無意味な文字列であり、認証証明書の取得は面倒で安全でないため、現在では何もかもが正しくないと述べた。最後に、Perlman氏は、常に「私はどのような問題を解決しようとしているのか」という問いから出発し、さまざまなアプローチを比較することを提案した。また、プレゼンテーションの序盤で、スライド操作に苦労した際、「私はコンピュータが嫌いです」と発言するユーモラスな場面もあった。
Perlman氏は、「Network Security: Private Communication in a Public World」や「Interconnections: Bridges, Routers, Switches, and Internetworking Protocols」という書籍の著者である。
注目のプレゼン Kappaアーキテクチャ、Sigstore、WebAssemblyについて
まずは、Chime社のスタッフ・ソフトウェア・エンジニアであるSherin Thomas氏による「Laying the Foundations for a Kappa Architecture - The Yellow Brick Road」をとりあげたい。Thomas氏は、KappaアーキテクチャをLambdaアーキテクチャの代替として紹介した。両者は、データ処理のためのデプロイメントモデルで、従来のバッチパイプラインとデータアクセスのための高速リアルタイム・ストリームパイプラインを組み合わせたものである。
彼女は、Lambdaの根本的な前提である"ストリームプロセッサが一貫性を提供できないというのは、Flinkのような最新のストリームプロセッサのおかげでもはや真実ではない"ということに基づいて、なぜLambdaアーキテクチャがいまだに人気があるのか疑問を呈した。Kappaアーキテクチャのルーツは、Kafkaの共同制作者であるJay Kreps氏（Confluentの共同設立者兼CEO）の2014年のブログ記事である。
Thomas氏は、Kappaアーキテクチャを、リアルタイム処理だけでなく、再処理やバックフィルにも対応できるストリーミングファースト、シングルパスのソリューションと位置づけた。また、Kappaアーキテクチャの原則を利用して、レイテンシーと一貫性のスペクトラムでさまざまなアプリケーションをサポートできる多目的データプラットフォームを開発者が構築できることを示した。Thomas氏は、ビームモデル、ストリームとデータレイクの両方への書き込み方法、データレイクをストリームに変換する方法について説明した。
最後に、Kappaアーキテクチャは素晴らしいが、万能ではないとの見解を示した。Lambdaアーキテクチャも同様で、デュアルコードパスにより、管理が難しくなっている。後方互換性があり、費用対効果が高く、汎用性があり、管理しやすいデータプラットフォームは、KappaアーキテクチャとLambdaアーキテクチャを組み合わせたものである可能性がある。
お次は、Chainguard社のスタッフソフトウェアエンジニアであるBilly Lynch氏と同社のリサーチサイエンティストであるZack Newman氏による、Sigstore: Secure and Scalable Infrastructure for Signing and Verifying Softwareと題したセッションを紹介しよう。開発ライフサイクルの各段階におけるセキュリティ攻撃の増加に対処するため、Lynch氏とNewman氏は、ソフトウェア成果物に署名し検証するための透明で安全な方法を提供することを目的としたオープンソースプロジェクトであるSigstoreを紹介した。
ソフトウェア署名は、アカウント認証やパッケージリポジトリの侵害を最小限に抑えることができ、ソフトウェアパッケージが "所有者 "によって署名されていることを確認できる。しかし、通常の脆弱性やビルドシステムの侵害などの攻撃を防ぐことはできない。従来のソフトウェア署名の課題としては、鍵の管理、ローテーション、侵害検知、失効、アイデンティティなどが挙げられる。
ソフトウェア署名は現在、オープンソースソフトウェアで広くサポートされているが、広く使われてはいない。デフォルトでは、ユーザビリティの問題や鍵の管理のために、ツールは署名をチェックしない。Sigstoreは、開発者を鍵の管理から解放し、二要素認証などの既存のアカウントセキュリティ手法に依存する。Sigstoreでは、OAuth（OIDC）でユーザー認証を行い、一時的なX.509コード署名証明書を発行してユーザーのIDにバインドする。
Lynch氏とNewman氏は、サブプロジェクトを含むSigstoreの概要説明とデモを行った。コンテナに署名するためのSigstore Cosign、Gitコミットへの署名を可能にするSigstore Gitsign、OAuthによるユーザー認証のためのSigstore Fulcio、署名が有効であれば証明書も有効といった透明性ログを付加できるSigstore Rekor、Kubernetesベースのアドミッション・コントローラーであるSigstore Policy Controller、各社のボランティアエンジニアが共同で運営・保守する特別利益グループであるSigstore Public Good Operationsなどだ。Certificate Transparency Version 2.0であるRFC 9162に触発されたSigstoreチームは、自分たちが行うすべてのことを暗号的に改ざんできないように公開ログとして提供している。
ソフトウェア署名は特効薬ではないが、有用な防御策である。ソフトウェア署名はDevSecOpsにとって重要である。そして、開発者は自分のソフトウェアを含めて署名の検証を始めるべきである。Perlman氏の基調講演で語られたX.509のセキュリティ上の懸念についてInfoQから質問されたNewman氏は、証明書は非常に複雑であると述べ、脆弱性がまだ証明書の中に入り込む可能性があることを認めている。しかし、Sigstoreは、X.509の認証を処理するために利用できる成熟したライブラリに満足しているという。また、Newman氏は、現在のやり方を廃止して一からやり直すという選択肢もあると述べた。しかし、この方法では、さらに多くの脆弱性が発生する可能性がある。
続いては、WebAssembly Componentsでより速く機能を構築する Cosmonic社ディレクターのBailey Hayes氏の講演である。Hayes氏は、WebAssembly（Wasm）モジュールの定義として、「多くの言語でサポートされるコンパイルターゲット」「アプリケーション全体に必要な.wasmファイルは1つだけ」「1つのターゲット言語から構築する」と説明した。
また、WebAssembly System Interface（WASI）は、WebAssemblyのモジュラーシステムインターフェイスで、POSIXでモジュールを展開するのは難しいので、本当はWebAssemblyStandard Interfacesとして知られるべきであるとHayes氏は主張していることを紹介した。続いて、WasmモジュールがWebAssembly Runtimeを介してWASIとどのように相互作用するか、またWasmモジュールの実行方法として、ExtismやAtmoなどのプラグインツール、FaaSプロバイダー、Docker、Kubernetesといった多くの方法があることが説明された。続いて、Wasmアプリケーションのデモが行われた。
Hayes氏は次に、文字列、レコード、バリアントといったWasm内の高レベルの型をサポートするWebAssembly仕様の拡張案であるWebAssembly Component Modelを紹介した。WASIを使ったWasmコンポーネントの構成要素を説明した後、コンポーネントを構築するプロセスを説明し、GoとRustで書かれたアプリケーションを構築してコンポーネントに変換するライブデモを行った。
最後に紹介するのは、Oracle の OpenJDK プロジェクト Loom のテクニカルリードであるRon Pressler氏による Virtual Threads for Lightweight Concurrency and Other JVM Enhancementsだ。 Pressler氏は仮想スレッドの出現について、多くの数学的理論を含む包括的な背景を説明した。並列処理と並行処理の比較では、それぞれレイテンシ（所要時間）とスループット（タスク/時間単位）で性能指標を定義している。長期的な平均値を持つ安定したシステムについては、L = λWとして、次のようなリトルの法則を紹介した。
- L = システムの平均アイテム数
- λ = 平均到着率 = 終了率 = スループット
- W＝1つのアイテムに対するシステム内の平均待ち時間（内部の持続時間）
スケジューリング/インターリーブポイントの観点からスレッドとasync/await、これらの属性をサポートする言語、すなわちJavaScript, Kotlin and C++/Rustにおいて定義されている実装、再帰/仮想呼び出しを比較してみせた。非同期プログラミング、構文コルーチン（async/await）、サーバーによるコンテキストスイッチの影響を紹介した後、Pressler氏は、Javaプログラミング言語におけるスレッドと仮想スレッドについて説明することですべてを結びつけた。
仮想スレッドは比較的新しい機能で、当初はJDK19で プレビューとして導入された。JDK 20で2回目のプレビューを行った後、仮想スレッドは2023年9月にリリース予定のJDK 21で 最終機能となる予定である。最後に、"誤解を招くような親しみやすさ"という言葉を、"学ぶべきことは多いが、学びほぐしすることも多い "と定義して締めくくった。