2023年6月14日、ニューヨークのブルックリンにあるNew York Marriott at the Brooklyn Bridgeで、第9回QCon New Yorkカンファレンスの二日目が開催された。3日間あるこのイベントは、エンタープライズ開発コミュニティにおける偏りのないコンテンツと情報に焦点を当てたソフトウェアメディア会社であり、InfoQとQConの運営元であるC4Mediaが主催している。Alicia Dwyer Ciancioloによる基調講演と、以下4つのテーマからのプレゼンテーションが行われた。
-
-
GoogleのソフトウェアエンジニアであるSilvia Esparrachiari氏が主催。
-
金融アプリケーション、ゲームプラットフォーム、その他技術業界の現実的なセグメントをカバーする多様な信頼性戦略のコレクションを提供する。
-
-
-
BentoML.aiの創設者であるBozhao (Bo) Yu氏が主催。
-
MLOpsの最新トレンド、ベストプラクティス、ケーススタディを探求し、機械学習システムの信頼性、スケーラビリティ、効率性を向上させるためにどのように適用できるかを議論。
-
-
-
モルガン・スタンレーの副社長兼シニアデベロッパーであるNeha Sardana氏が主催。
-
データ侵害、プライバシー、セキュリティ、パフォーマンスなどの課題に対する解決策を提案し、Fintechの最新トレンドとベストプラクティスを常に把握。
-
-
高速フローのためのチームの最適化 - ポスト・アジャイルの余波の中で生き残るために
-
Planview Flow MethodologyのシニアプロダクトマネージャーであるKatharine Chajka氏が主催。
-
フローを遅らせている具体的な問題を特定し、解決に向けて変更に費やした時間と費用を最大限に活用する方法に重点を置く。
-
また、スポンサード・ソリューション・トラックも1つ用意された。
C4MediaのコンテンツプロダクトマネージャーであるDanny Latimer氏は、2日目の活動を開始し、参加者を歓迎した後、InfoQニュースマネージャーのDaniel Bryant氏を紹介し、InfoQニュース活動やInfoQコアバリュー（情報ロビンフード、ベスト、ファーストではない、リーダーではなく促進者、信頼されるコンテンツ）について説明した。C4Mediaのプロジェクトマネージャー兼ダイバーシティリードであるPia von Beren氏は、QCon Alumni Programと複数のQConカンファレンスに参加することの利点について述べた。2日目のトラックリーダーは、自己紹介と各トラックのプレゼンテーションについて説明した。
基調講演NASAの月への帰還
NASAラングレー研究所の高度突入・降下・着陸機技術開発シニアテクニカルリーダーのAlicia Dwyer Cianciolo氏は、「NASAの月への帰還」と題し、アルテミスプログラムにおける複雑性の管理」について発表した。Cianciolo氏は、1962年にライス大学で行われたジョン・F・ケネディのスピーチから有名な言葉を引用してプレゼンテーションを始めた。「私たちがこの10年で月に行き、他のことをするのは、それが簡単だからではなく、難しいからである」。それを踏まえて、アポロ計画の「妹分」とされるアルテミス計画を、プロジェクトの集合体として紹介した。
アルテミス＝宇宙ロケットシステム＋オリオン宇宙船＋有人着陸システム（HLS）＋船外活動・人体表面移動計画（EHP）＋ゲートウェイ
Cianciolo氏は現在、有人着陸システムの開発に携わっている。アルテミスとその構成プロジェクトは、宇宙ミッションのためのコラボレーションとして設計された。それぞれのプロジェクトを紹介した後、過去に打ち上げられたアルテミスや今後打ち上げられる予定のアルテミスの背景や軌道情報などを紹介した。
2022年11月16日に打ち上げられ、12月11日に飛散したアルテミスIは、スペース・ローンチ・システムとオリオンのプロジェクトが紹介された。2024年末に打ち上げ予定のアルテミスIIは、スペース・ローンチ・システムとオリオン・プロジェクトをフィーチャーし、フライトクルーには、Reid Wiseman氏（船長）、Victor Glover氏（パイロット）、Christina Hammock Koch氏（ミッションスペシャリスト）、Jeremy Hansen氏（ミッションスペシャリスト）。アルテミスIIIの計画は月面着陸で、スペース・ローンチ・システム、オリオン、HLS、EHPの各プロジェクトが採用され、さらに未定のフライトクルーが加わる予定である。
HLSに関連する複雑な運用について、ミッションセグメント、契約、着陸要件、ゲートウェイ軌道を含むと説明された。アポロ11号からアポロ17号までは、月の赤道付近で着陸している。アルテミスIIIの着陸計画は、月の南極は地形が荒いため、緯度6度以内、表面勾配10度未満で着陸することになっている。もう一つの課題は、変化する日照時間である。クルーは6日間の日照時間を確保し、常に地球と交信する必要がある。 "何が問題なのでしょうか？" とCianciolo氏は尋ねた。
月へ行くのに一番難しいのは、人と話をすることです、Cianciolo氏は言った。
アルテミスIVの計画は、スペースローンチシステム、オリオン、HLS、EHP、ゲートウェイの各プロジェクトを搭載した国際居住モジュールに着陸し、決定されたフライトクルーを乗せることである。
注目のプレゼン：パフォーマンス、データ構造、ChatGPT
Chronical Software社のCEOであるPeter Lawrey氏は、「Vertical Scalabilityと効果的なテストによる金融取引システムのパフォーマンスと効率の最大化」と題して講演した。Lawrey氏はまず、オブジェクトの割り当てが、ガベージコレクションに比べて80倍ものオーバーヘッドになる可能性があることを説明した。彼は、オブジェクトの損失は割り当てることができると主張したが、これまで実践されてきたこの戦略に対しては推奨している。伝説的なグレース・ホッパーはかつて "英語の中でもっとも危険なフレーズは、「私たちはいつもそのようにしてきた」" だと述べた。
彼は、アロケーションがうまくスケールしない理由について、さまざまな分析とベンチマークを示した。アロケーションはガベージコレクタで約0.3%の時間を費やす可能性がある。偶発的な複雑さという概念は、問題に内在する複雑さではなく、より良い設計や技術の選択によって取り除いて減らすための解決策である。
Lawrey氏は、偶発的な複雑さに関する多くの例と分析を提供し、その中には、割り当て活動のほとんどがJDK Flight RecorderからのものであるChronical Queueのメモリ使用量分析が含まれていた。多くのアプリケーション、特に金融業界では、「信頼できる情報源」を選択することが、アプリケーションのレイテンシーと複雑性に大きな影響を与える。
耐久性保証の概念は、パフォーマンスにとって重要なパスを特定するが、最大のボトルネックと見なされることが多い。例えば、データベース、ディスク上にあることが保証された耐久性のあるメッセージング、冗長なメッセージング、最終的にディスク上になる永続的なメッセージングなどである。Lawrey氏は、待ち行列理論における創始的な原理であるリトルの法則を、L = λとして、次のように紹介した。
- L = システム内のアイテムの平均数
- λ = 平均到着率 = 終了率 = スループット
- W＝あるアイテムに対するシステム内の平均待ち時間（内部の持続時間）
リトルの法則は、システム設計や性能向上の多くの局面で応用されている。待ち時間が長ければ長いほど、望ましいスループットを達成するために必要な固有の並列性が高くなる。その反対に、レイテンシーが低ければ低いほど、本来必要な並列性は小さくなる。Javaの従来のオブジェクト割り当てでは、特に高スループットのシナリオでパフォーマンスを阻害し、垂直方向のスケーラビリティを妨げるボトルネックとなる可能性がある。偶発的な複雑さを最小限に抑え、イベント駆動型アーキテクチャを採用することで、垂直方向のスケーラビリティを実現が可能だ。
BNY Mellonのマネージングディレクター兼著名エンジニアであるDonald Raab氏とComputas ASのチーフエンジニアであるRustam Mehmandarov氏は、「パフォーマンスとスケール-Domain-Oriented Objects vs Tabular Data Structure」を発表。Raab氏とMehmandarov氏は、2004年当時、32ビットと64ビットの両方のメモリを使用したインメモリJavaアーキテクチャの問題点を回顧することから話を始めた。32ビットの世界では、例えば6GBのデータを4GBのメモリに配置することは、開発者にとって難しいことであったが、独自の「スモールサイズ」Javaコレクションを構築することで解決した。
64ビットの出現で多少は緩和されたが、ヒープサイズの合計が問題になった。2006年末にリリースされたJava 6で利用できるCompressed Ordinary Object Pointers（OOPS）により、開発者は64ビットヒープで32ビット参照（4バイト）の作成が可能になった。この場合の解決策としては、メモリ効率の良いミュータブルなSet、Map、Listデータ構造を独自に構築すること、List、Set、Stack、Bag、Mapデータ構造用のプリミティブコレクションを構築することが挙げられる。
次に、Raab氏とMehmandarov氏は、大きなCSVデータをメモリ上で処理する必要がある場合を例に、開発者が今日直面している課題について説明した。「Javaで効率よく処理するにはどうすればよいか」「データ構造のメモリ効率はどのように測定すればよいか」「メモリ効率に影響を与える決定事項は何か」「行と列のどちらのアプローチがよいか」。Javaにおけるメモリのコストを測定するために、Raab氏とMehmandarov氏は、JVMにおけるオブジェクトレイアウトスキームを分析するための小さなツールボックスであるJava Object Layout（JOL）と、それをアプリケーション内で使用する方法について紹介した。
大規模なCSVデータセットを例に、ボックス型とプリミティブ型、可変と不変データ、データプール、行ベースと列ベースの構造など、さまざまなメモリに関する考慮事項を包括的に説明した。また、3つのライブラリについても解説した。Java8で導入されたJava Streams、Raab氏が考案したEclipse Collections、Eclipse Collectionsフレームワークをベースにした表形式のデータ構造であるDataFrame-ECだ。3つのJavaプロジェクト、Amber、Valhalla、Lilliputの3つのJavaプロジェクトは、それぞれ生産性の向上、オブジェクトとユーザー定義プリミティブの価値向上、オブジェクトヘッダの64ビットへの削減などに取り組んでいる。
(AI)マインドのための自転車：GPT-4 + Toolsは、OpenAIの技術スタッフであるSherwin Wu氏と、OpenAIのソフトウェアエンジニアであるAtty Eleti氏が発表した。1973年、コンドルに例えられるようなサイクリングの効率性が現れはじめた。Wu氏とEleti氏は「A bicycle for the mind」という言葉を作り、これをスティーブ・ジョブズ氏とAppleの創設の比喩として用いた。2023年、ChatGPTの出現により、この言葉は "A bicycle for the AI mind "に発展した。
Wu氏とEleti氏は、大規模言語モデル（LLM）とその限界について説明し、gpt-4 と gpt-3.5-turbo アプリケーションの改善に向け新しい関数呼び出し機能を紹介。Wu氏とEleti氏は、自然言語をクエリーに変換する、外部APIや複数の関数を呼び出す、高度な推論を日常的なタスクと組み合わせる、といったデモを数多く行った。2人は「技術はまだ発展途上であり、この技術が今後どのように進化していくのか楽しみです」と述べた。
OSSF Scorecardsの組織全体への導入については、atsignのエンジニアであるChris Swan氏が発表した。Swan氏は、Open Source Security Foundation（OSSFまたはOpenSSF）を"業界でもっとも重要なオープンソースセキュリティの取り組みと、それをサポートする個人と企業をまとめる業界横断的な組織"として紹介した。
OpenSSFScorecardプロジェクトは、OpenSSFのプロジェクトの1つで、オープンソースのメンテナがセキュリティのベストプラクティスを改善し、オープンソースの消費者が依存関係が安全かどうかの判断を支援する。重要なソフトウェアセキュリティのヒューリスティックをオープンソースソフトウェアプロジェクトに対して測定し、0～10のスコアを割り当てる。ヒューリスティックとスコアを含むバッジが生成され、GitHub リポジトリに配置ができる。これにより、オープンソースリポジトリのメンテナがセキュリティへの意識を視覚的に表現し、安全性と安心感を与えることができる。
Swan氏は、コードの脆弱性、メンテナンス、継続的なテスト、ソースリスク評価、ビルドのリスク評価という5つのセキュリティの考え方について説明した。彼は、OpenSSFに初めて参加する開発者に対し、自身のオープンソースプロジェクトのセキュリティを評価する出発点として、同じくOpenSSFのプロジェクトであるAllstarの使用を勧めた。Swan氏は、以下のようなツールを探求することで、どのように始めればよいかを包括的に紹介した。GitHub Insightsは、開発者が良質なオープンソースリポジトリを作成するためのガイドとなるツールであり、Terraformは、GitHubリポジトリを改善するためのスクリプトを提供するIaaS（Infrastructure as a Service）リソースである。
また、このプロセスには非常に長いアンケートが含まれており、開発者は最低でも1時間程度時間を割く必要がある。OpenSSFの80:20ルールでは、Scorecardのスコアの80%を得るためには、20%の労力が必要であるとされている。しかし、そこから先は難しくなり、高得点を獲得するのは非常に困難だとSwan氏はコメントした。