企業システムでのSpring活用事例も多数紹介
ここからは、企業システムでSpring Frameworkを実際に活用している事例として、野村総合研究所、LINE、サイバーエージェントの皆さんに講演いただいたセッションを紹介します。
セッション「事例で知る！大規模エンタープライズ開発現場のリアル」
野村総合研究所でSpringベースの開発フレームワーク「オブジェクトワークス」の導入推進を行っている大知弘典さんは、オフショアを前提とした大規模システム開発の現場で起きた“あるあるな問題事例”と、その解決ストーリーを紹介してくださいました。
最初に紹介されたのは、一覧画面表示時にOut Of Memory Errorが発生する問題です。調べてみると、検索結果の上限件数がなく、DBから取得した検索結果を毎回セッション領域に格納していることが原因と分かりました。よくあるアンチパターンですが、大知さんはこの問題に対し、次の3つを標準化・共通チームとして行うべきだったと述べられました。
- 画面設計工程へのルール策定：検索結果の上限などをあらかじめルール化しておく。画面設計はステークホルダーが多いため、設計の初期段階でお客様や関係者を巻き込んでの標準化がポイント
- 開発工程へのルール策定：セッション領域の利用を申請制にする。ルールが破られることを前提に、ソースコードを自動検証できる仕組みを用意しておくことがポイント
-
開発工程への部品作成：セッション領域のデータを不要になったタイミングで削除する機能を、共通部品として提供する。Spring Frameoworkが提供する
@SessionAttribute、SessionSatus.setComplete()を使うことで簡単に実装できる。
この他に紹介された事例は「ヒストリーバック時の有効期限切れ画面問題」「エラーハンドリング握りつぶし問題」「Controllerクラス分割粒度バラバラ問題」など。いずれも、オフショアでの大規模システム開発の経験者であれば思わず“あるある！”とうなずいてしまうものばかりでした。また、それぞれの問題に対してSpring Frameworkを活用することで簡単に対応できる点も分かりやすく説明されていました。
技術が進歩しても標準化の重要性は変わりません。問題の発生を未然に防ぐためには、開発現場のリアルを知り、技術と人をつないでいく地道な活動が求められているのだと感じるセッションでした。
セッション「LINEにおけるSpring Frameworkの活用」
LINEで自社サービスのサーバーサイド開発を担当されている松野徳大さんは、LINE社内でのSpring Frameworkの活用事例として、Spring Bootを利用した「LINE Notify」の開発を紹介してくださいました。
松野さんの調査によると、LINEの社内システムは約41％がJavaで実装されており、その多くでSpring Frameworkが利用されているそうです。Java EEと比較して開発のサイクルが速いこと、スケーラビリティが求められるBtoC向けWebサービスでの事例が多いことなどが、Spring Framework採用のポイントだとおっしゃっていました。
「LINE Notify」は、外部のサービスからLINEユーザーに通知を送れるサービスで、curlコマンド1つでAPIを利用できるシンプルさが特徴です。開発では最新のSpring Boot 1.4を採用し、わずか2か月で完成させたとのこと。導入が容易で、デプロイや起動が高速に行えるSpring Bootの特徴が生かされたようです。また、XMLの記述が不要という点が、開発者にとって大きなメリットになったと感じているそうです。
この開発では脱XMLに徹していたようで、O/R MapperのMyBatisで必要となるSQL文の定義を、XMLに記述するのを避けるため、JVM言語の1つ「Kotlin」を部分的に利用したそうです。Spring BootはKotlinもサポートしていますので、簡単な設定ですぐ実装を開始できる点がうれしいですね。
ちなみにLINE社内には、MyBatisのSQL文をアップするとDBAがクエリ評価をしてくれるサービスがあるそうです。Spring Bootで開発効率を高めつつ、性能面は手堅く作り込もうという姿勢がうかがえます。
セッションの最後に、「LINE Messaging API」の取り組みが紹介されました。これはLINEのBotを簡単に作れるAPIで、もちろんSpring Bootもサポートしているそうです。現在「LINE BOT AWARDS」という大規模なコンテストを開催中で、なんと最大優勝賞金は1000万円！ 締め切りは2017年2月下旬ということなので、Spring Bootの経験者は腕試しで、未経験者は勉強のきっかけとしてチャレンジしてみてはいかがでしょうか。
セッション「アメブロの大規模システム刷新とそれを支えるSpring」
サイバーエージェントでサーバサイドエンジニアを務める向井政貴さんと服部拓也さんは、会員数5300万人を誇るアメーバブログ（以下、アメブロ）を支える大規模システムの刷新を紹介してくださいました。
サービス開始から約12年が経過したアメブロのシステムは刷新前、様々な技術的負債を抱えていたそうです。利用技術が古く、フレームワークは混在し、類似機能が複数プロダクトに重複しているといった状況で、保守性が低く、開発コストが増大していました。
そんな中、データセンターの移設が決定。これを機会として、アメブロのシステムを作り直すことになりました。スケジュールや障害発生時の影響の大きさやリスクを考えると、作りを変えずに単純移行する選択もありました。しかし、「現状を打破したい」という強い信念のもとに刷新を決意されたそうです。
刷新にあたっては、社内での採用実績の多さやローカル開発環境の作りやすさ、アーキテクチャを統一しやすいことなどから、Springを採用。Springのレイヤードアーキテクチャに従うことで、それまでバラバラだった処理の記述場所が統一され、再利用性や可読性が向上しました。また、SpringfoxとSwaggerによりAPIドキュメントを自動生成する仕組みを導入し、保守性の向上に役立てているそうです。
また、開発コストを抑えるために、それまでプロダクトごとに分散していたリポジトリを1つに統合し、マルチプロジェクト化することにも取り組まれました。リポジトリの統合により、リリースジョブの共通化が図れ、処理の見通しのよさや共通化のしやすさでメリットがあったそうです。
しかし、リポジトリを統合したことで不要なクラスまでBean化されるようになり、起動時間やメモリ使用量に悪影響が出てしまいました。この問題を解決するには、読み込むクラスをレイヤーごとに適切に絞り込む必要があります。そこで、Serviceを絞り込むための独自アノテーション@Facadeを設けました。さらに、Repositoryを絞り込むため、接続先DBの宣言情報に基づいて関連するRepositoryだけをBean化するInitializerを設けました。
アメブロの刷新によって得られた効果は、技術面だけではないそうです。ビジネス面では迅速性や柔軟性が向上。組織面では新規人材を加えやすくなったほか、よりよいサービスにしようという意識がメンバーの間で強くなったといいます。セッションの最後、向井さんは「本当にやってよかった」と熱く語っていました。日本最大級のブログサービスは、技術者の信念と情熱に支えられているのだと感じるセッションでした。
おわりに
本稿では、Spring Day 2016の様子と主なセッションの内容をレポートしました。セッション終了後には同会場にてディナーパーティとライトニングトークが行われ、講演者と一般参加者が夜遅くまで語り合い、熱気冷めやらぬまま幕を閉じました。
なお、本記事のレポーターを務めたNTTおよびNTTデータのメンバーも、以下2つのセッションで講演させていただきました。Web上でスライドを公開していますので、興味があればぜひご覧ください。
