新技術の活用と開発の高速化が同時に求められる現在において、ユーザー企業の情報システム部はどのような体制で開発に臨むべきなのか。
富士フイルムソフトウエアの佐藤 力氏 |
リプレイスをきっかけに、プラットフォームと開発体制の切り替えを実現した富士フイルムソフウエアの事例が「de:code 2017」で紹介されたので、その模様をご紹介しよう。
伊勢志摩サミットの公式フォト基盤
「IMAGE WORKS」が抱えていた課題
講演に登壇したのは、富士フイルムソフトウエアで社内ベンチャービジネスの責任者を務める佐藤 力氏と、フリーのITアーキテクトとして活躍するゼンアーキテクツの岡 大勝氏。両氏は、富士フイルムが提供するイメージファイル管理/共有サービス「IMAGE WORKS」の刷新に共に挑んだ”戦友”だ。
Java/Struts/PostgreSQLによるレガシーWebシステムとして稼動していたIMAGE WORKSの運用に限界を感じていた佐藤氏。有効な手立てを見つけられずに困り果てていたときに岡氏のITモダナイゼーションのセミナーを聴講。内容はメインフレームのリプレースだったが、Webシステムにも応用できるのではないかと考え、協力を依頼したという。
IMAGE WORKSは、1日の登録データ量が約1TB、リクエスト数は500万回、ユーザー数約4万人、ピーク時トラフィック量800Mbpsという巨大システム。日本野球機構らを顧客に持ち、G7 伊勢志摩サミットの公式フォトを提供する基盤に選ばれるなど実績も豊富だ。
しかし、オフショア開発で構築した経緯もあり、ソースコードはぐちゃぐちゃ。PostgreSQLのチューニングも不可避な状況だが、手を付けられずにいた。メンテナンスにはStrutsの知識が必要で運用は属人化しつつあったというのも問題の一つに挙げられる。
さらに、ストレージサービスだけに拡張も適宜必要になるが、そのためにはサーバの納品などで一ヶ月程度待たなければならない。また、月に一度、メンテナンスのためにサービスを停止していたが、止められては困るという意見を寄せる企業もあったという。
設計案には全員が反対
こうした課題を前に、開発期間やコストを抑えつつ、止めずにリプレースする戦略として岡氏が打ち出したのが「PaaSによるラッピング」である。
ゼンアーキテクツの岡 大勝氏 |
「今回のような場合、同じものをゼロから作り直す“リビルド”を選択するケースもありますが、うまくいった話を聞いたことがありません。大抵はメンテナンスされたドキュメントがないため、調査に時間がかかります。さらに作っていく過程であれもこれもと要件が足され、開発ボリュームがどんどん膨れていくケースがほとんどです。
現実的なのは、既存の資産を活かす方法。バックエンドでAPI連携させながら、Azureの拡張性や自動化機能を活用する設計が良いのではないかと考え、PaaSのラッピングを選択しました」(岡氏)
この戦略に対して、佐藤氏は賛同したものの、富士フイルムソフトウェアのエンジニアは全員が反対。
「旧システムを活かすならクラウドまで使う必要はないといった意見もあり、今思えば理解が追いついていなかった」(佐藤氏)というのが理由だが、なかには「佐藤さんは、怪しいコンサルタントに騙されているのではないか」と訝しむ人すらいたという。
しかし、だれに聞いても対案がないことから佐藤氏は強行。「確信はありませんでしたが、うまくいけば“一石四鳥”の案。岡さんを信じて進めることにしました」(佐藤氏)。
PaaSのラッピング、なぜそんな設計を選ぶのか
新基盤の骨子はこうである。
フロントエンドはAzureを活用してフルPaaSで作り直す。一方、Java/Struts/PostgreSQLの旧システムはAPIでのみ連携できるかたちに改修して、バックエンドで再利用。データはAzureから旧システムへ送り、旧システムに格納するかたちをとる。
フロントエンドのAzureで更新リクエストを受けるとそれを旧システムへ送り、PostgreSQLのデータを更新。さらに更新した内容は、「Cache-Asideパターン」に従うかたちで非同期でフロントエンドのAzureへ戻し、JSON形式でデータストアに格納する。つまり、フロントエンドにキャッシュデータを置くかたちで、ユーザー向けに高レスポンスな環境を提供する。
予定の開発期間は6ヶ月。だれもやったことのない挑戦であったため、岡氏を中心としてPoC(Proof of Concept)を作りながら判断するかたちをとった。予定の2カ月で動くものができ、「もう1ヶ月ください」と社内で調整。「さらに順調に進んだのでもう1ヶ月ください、などと進めるうちに、本当に6ヶ月でモダナイゼーションが完了してしまったんです。昨年11月の出来事でした」(佐藤氏)