Javaは戦略的プラットフォーム──ゴールドマン・サックスが実践するJava標準化、オープンソースへの取り組み

Oracle Java & Developers編集部
2015-05-22 11:00:00
  • このエントリーをはてなブックマークに追加

世界最大級の投資銀行として知られる米国ゴールドマン・サックスは、社員の4分の1がIT部門所属というテクノロジー企業でもある。そんな同社は、自社システムの開発でJavaを利用するだけでなく、JCPにおける標準化プロセス、OpenJDKの開発にも積極的に関与している。

社員の4分の1がIT部門に所属。DevOpsを地で行くゴールドマン・サックス

ゴールドマン・サックス テクノロジー部 ヴァイス・プレジデントの伊藤博志氏
ゴールドマン・サックス テクノロジー部 ヴァイス・プレジデントの伊藤博志氏

 「餅は餅屋に」の言葉にならい、システム開発を専門の会社に任せる企業は少なくない。その一方で近年、アプリケーション・リリース・サイクルの短期化やモバイル化の流れを受け、「自社で使うシステムは、自社で開発する」というスタイルを実践する企業が増えている。

 そうしたITに深くコミットする企業の代表例と言えるのが、世界有数の投資銀行である米国ゴールドマン・サックスだ。日本オラクルが2015年4月に都内で開催したJava開発者イベント「Java Day Tokyo 2015」では、『ゴールドマン・サックスのJavaへの取り組み』と題した講演が行われ、独自フレームワークの開発や「OpenJDK」の活用など、Javaに関して同社が精力的に進める取り組みの内容が紹介された。

 講演に登壇したゴールドマン・サックス テクノロジー部 ヴァイス・プレジデントの伊藤博志氏によれば、同社には「自分たちが使うツールは自分たちで作る」という文化が根付いており、全社員の4分の1をIT部門スタッフが占める背景にも、この企業文化があるという。

 伊藤氏が所属するテクノロジー部では、トレーディングや決済、レポーティングなどのアプリケーションの開発からインフラの構築/運用までを行っている。昨今、開発と運用を一体化させたアプローチを「DevOps」と呼ぶが、この呼称が生まれる以前からゴールドマン・サックスではDevOpsを実践してきた。

 そんな同社は、早い段階からJavaに注目。1998年に社内での技術評価を開始し、2000年にはJavaを戦略的プラットフォームの1つに位置づけ、主要な開発言語に据えている。当時から、Javaに不具合などを見つけると、パッチを作成して開発元(当時はサン・マイクロシステムズ、現在はオラクル)に提供するといった活動を行っていたという。そして2004年には、後述する「GS Collections」の前身となるフレームワークの開発に着手し、2012年にオープンソースとして公開。また同年、JCP Executive Committeeに選任され、Java SE 8で導入されたラムダ式などの仕様策定に深くかかわってきた。

 現在、ゴールドマン・サックスには3000名を超えるJava開発者が在籍しており、同社のシステムでは1時間当たり約12万5000ものJavaプロセスが稼働しているという。


※クリックすると拡大画像が見られます

ゴールドマン・サックスが進めるOpenJDK活用のメリットとは?

 これまで15年以上、Javaと深くかかわってきたゴールドマン・サックスは、2013年からOpenJDK(http://openjdk.java.net/)の開発に参画しており、自社システムでもOpenJDKを積極的に活用しているという。OpenJDKを採用する大きな目的の1つとして伊藤氏が挙げるのは「トラブルシューティング」だ。

 「アプリケーションやJVMの挙動がおかしいとき、JVMのコードを調べることで原因が判明することがありますし、そもそもJVMが原因だったということもあります。そのようなときには、回避策を取ったり、パッチを作成/提出して採用されるのを待ったりします。ただし、パッチが採用されるまで待てないほど緊急性が高いときには、自社でJVMをビルドして使うこともあります。ソースコードが公開されているOpenJDKなら、そのようなことができるのです」(伊藤氏)

 トラブルシューティングの具体例として、伊藤氏は監視用のJVMTI(Tool Interface)エージェントが次のようなエラーを出力し、JVMがクラッシュするという問題を紹介した。

【JVMTIエージェントが出力するエラー・メッセージの例】


*** java.lang.instrument ASSERTION FAILED ***: "error == JVMTI_ERROR_NONE" 
at ../../../src/share/instrument/Reentrancy.c line: 161

 「発生パターンから当たりを付け、テスト・ケースを作って検証したところ、デーモン・スレッドがシャットダウン中にクラス・ローディングを実行すると、この問題が発生することを確認しました」(伊藤氏)

 そして、OpenJDKのソースコードを確認しながらバグ・データベースを調べたところ、過去に「シャットダウン時にコンディション・チェックを追加する」というバグ修正(JDK-6572160)が行われているものの、いくつかのユーティリティ関数でこのチェックが抜けていることがわかった。

 「そこで、当社のメンバーがパッチを作成してOpenJDKのコミュニティで検討してもらった結果、JDK 8の開発ブランチで採用されました。その後、このパッチはJDK 7にもバックポートされています」(伊藤氏)

 また、OpenJDKを利用するもう1つの大きな目的として、伊藤氏は「新機能のリサーチ」を挙げる。

 「OpenJDKには、JavaやJDKに追加される機能がいち早く実装されます。それらの新機能を自社のアプリケーションでどう活用できるかを検討し、有効そうならば実際に試してみます。そうしたことが可能なプラットフォームとして、OpenJDKは非常に有用なのです」(伊藤氏)

 その具体例として、伊藤氏は「圧縮OOP(CompressedOops)機能」を紹介した。これはオブジェクトの参照アドレスを64ビット(8バイト)から32ビット(4バイト)に圧縮することで、参照オブジェクトのヒープ・サイズを削減するというものだ。

 「圧縮OOPは便利な機能ですが、当初は適用できるヒープ・サイズの上限が32GBまでという制限があり、当社のアプリケーションにはこの制限に抵触するものが多くありました。そこで、上限を64GBに引き上げるパッチを作成して独自ビルドで検証し、その有効性を確認したうえで社内の開発者に提案することができました。これは圧縮OOPがJVMでデフォルトとして採用される前のことです」(伊藤氏)

 なお、オープンソース開発のメリットとして「ソースコードにアクセスできること」が挙げられるが、伊藤氏によれば、それと同じくらい重要なのが「開発プロセスに透明性があること」だという。

 「OpenJDKコミュニティのポータルには、開発の過程で行われたディスカッションの記録が残されており、バグ・データベースも公開されています。これらの情報は、何か問題が発生した際の解決の手助けになるだけでなく、機能を深く理解して活用するためにも役立つのです」(伊藤氏)