【デブサミ2019】セッションレポート（AD）

Infrastructure as Codeの実践やマイクロサービス開発でモダン開発に挑戦【デブサミ2019】

【14-E-2】レガシー開発からモダン開発への挑戦

2019/03/14 12:00

ポスト

　自動車アフターマーケットを中心に、幅広い業種・業界の現場業務を支援するソフトウェアやITソリューション、各種サービスなどを提供している株式会社ブロードリーフ。同社では、より効率的で高品質な開発体制を実現するべく、インフラとアプリケーションの両面からモダン開発への移行にチャレンジしている。セッション前半では、老朽化したデータセンターをクラウドに移行するプロジェクトでのInfrastructure as Code導入について発表。また後半では、Spring Bootを使ったマイクロサービス開発についての発表があり、それぞれの担当エンジニアが最新の成果やこれからの展望について報告した。

ポスト

講演資料：今どきのインフラはペットでは無かった（左近充裕樹氏）
講演資料：Spring Bootでマイクロサービス作って苦労したお話（松本宏紀氏）

データセンターのハード更新を好機にIaCの実践へのチャレンジを決意

　ブロードリーフがInfrastructure as Codeの実践にチャレンジするきっかけとなったのは、データセンターのサーバーの老朽化だ。左近充氏はそれ以前を振り返って、「当社のオンプレミスの暗黒時代だった」と明かす。

　左近充氏が担当になった時点で、すでに構築当時を知る社員は残っておらず、協力会社のベテラン社員に聞いては立ち上げ時の状態を推測していたと言う。また長い間にハードウェア構成が変更され、ベンダーから来た資料と微妙に合わない。緊急対応などで増改築を繰り返した部分も多く、実際の構成を知るには、そのつど現地調査に赴かなくてはならなかった。

　「必要なドキュメントがなくブラックボックス状態になっていた上に、当時を知るメンバーが抜けて情報が薄くなっており、まさに"水をつぎ足した秘伝のタレ"のようなありさまでした」

　そうしたある日、2か所あるデータセンターの一方のハードウェアが老朽化し、パブリッククラウド（AWS：Amazon Web Services）への移行が決定した。これをインフラチームでは千載一遇のチャンスととらえ、「昨今話題のInfrastructure as Code（IaC）を取り入れようと決めた」と左近充氏は言う。

　改めて言うまでもないが、IaCとはシステムのインフラ設計をコードとして記述し、プロビジョニングと構成・設定および変更の自動化を含む、インフラ構築の効率化を図る手法だ。左近充氏は、「人力では避けられないオペレーションミスを回避する上でも、IaCは極めて有効な手段です。このとき参考にした書籍（注1）の、『サーバーはペットではなく畜牛のように扱え』～従来のように大事に維持するのでなく、目的に応じてどんどん使っていけ～という言葉は、プロジェクトを進める指針になりました」と語る。

注1

　『Infrastructure as Code―クラウドにおけるサーバ管理の原則とプラクティス』（オライリー・ジャパン刊）による。

TerraformとAnsibleを組み合わせ、すべてコードで管理できるまでに進化

　今回のサーバー移行では、2つのデータセンターを順番に移行していった。最初の移行でインフラ構成管理ツールとして採用されたのが、HashiCorp社のOSSであるTerraformだ。選択理由としては、「（1）Go言語で書かれており、Windows／Mac／Linuxのどれでも動作する」「（2）AWS、Azure、GCP（Google Cloud Platform）、OpenStack、Herokuなどさまざまなプロバイダが提供されている」といった点が挙げられると左近充氏は言う。

　「特に注目したのは、OSSでありながら開発が非常に活発なことです。試しに私がイシューを上げてみたところ、1か月もしないうちに修正されるなど、開発のスピード感が感じられました。また同じ構文を異なるプロバイダのパブリッククラウドに適用できるので、ベンダーロックインが避けられるメリットもあります」

　1回目の成果をもとに、次のデータセンター移行では、インフラ構成管理ツールにHashiCorp社のOSSであるPackerを採用。また別の新規商材（Webアプリケーション）のインフラ開発ではクラウドプラットフォームにGCPを使うなど、ツールやプラットフォームを変えながら挑戦を重ねた。現在ではOS以上のレイヤのプロビジョニングまでを含む全インフラを、TerraformとAnsibleを組み合わせて、すべてコードで管理できるまでに進化しているという

　「この次は自動復旧を目標に、自律型システムの実現を目指していきたいと考えています。これからIaCにチャレンジする方は、前例がないといった批判なども受けると思いますが、経験がないことにPDCAは通用しません。未経験のことをPlanするよりも、いち早くDoを実践することでPlanの糸口もつかめるようになります」

2回目のデータセンター移行（DC2）では、すべての階層のプロビジョニングがIaC化された

さまざまなツールを駆使して起動時間を65秒から28秒に短縮

　続いて登壇した松本氏は、「Spring Bootでマイクロサービスを作って苦労したお話」と題して、自社でのSpring Bootを使ったマイクロサービス開発の事例について発表した。

　もともと「マイクロサービスアーキテクチャ的なサービス開発」を手がけてきた松本氏だが、「現在もSpring Bootをベースに、その上にデータを扱うためのデータフレームワークやKPIを作成するためのフレームワークを乗せ、さらにその上に各サービスを実装するという構成で、約43個のマイクロサービスを運用しています」と言う。

　松本氏は、これらのサービスを開発していてもっとも辛かったのが、「待たされる」ことだったと明かす。待たされる原因は大きく2つ。「アプリケーションの起動が遅い」と「アプリケーションのテストが遅い」だ。

　「開発中に動作確認を行いたいのに、待たされる。手順としてはビルド→デプロイの流れでパイプラインが動くのですが、デプロイだけでもおよそ65秒かかります。これは、作業効率の面でも精神面でも大きなストレスです」

　そこで松本氏がまず実行した解決策が、spring-context-indexerの導入だった。これで起動時間48秒を43秒まで5秒短縮したが、まだまだ十分ではない。そこで、さらにApplication Class-Data Sharing（JEP 310）を導入した。これはJava 10から提供されている機能で、VM上の内部表現を先にダウンロードして、Javaのプロセス起動時にそれを読み込むことでスピードを上げる仕組みになっている。

　「いろいろ問題があって使いにくいところもありましたが、最終的に起動時間43秒が28秒に短縮されました。一方ビルド時間は逆に15秒→3分へと増えましたが、起動時間だけで見れば、対策前の65秒から差し引きで37秒の大幅な短縮です。これで起動が遅いという問題は、ひとまず解決できました」

Spring Bootでの成功体験をもとに、さらに新しいチャレンジを目指す

　次に取り組んだのが、もう一つの課題である「テストが遅い」だ。これまでは、ビルドが終わってデプロイ前のテストに11分かかっていたと言う。

　「もちろんテストは非常に大事なのですが、これだけ長い時間かかるとさすがに待っていられないので、他の作業をしてしまいます。その結果かえって時間がかかったり、気分的にも緊張感をそがれてしまいます。そこで改善策を講じたところ、テスト時間を2分にまで縮めることができました」

　ここで行った対策は2点のみ。1つは、よくある起動時のオプションのチューニングだ。これだけで11分が9分に短縮した。これをさらに縮めたのが、Maven Surefire PluginのreuseForksをtrueに変更したこと。これによって、9分を一挙に2分にまで縮めることができた。

　起動時間とテストのトータルでは、最終的に従来の12分が半分の6分に短縮されたことになり、今回の試みは十分に成功したと言えるだろう。もちろん反省点も数多くあったと松本氏は指摘する。

　「実際に取りかかる前によく考えておくべき、詳細なポイントがいくつもありました。そうした反省点を踏まえて、今後はSpring Bootをより効果的に使いこなしていきたいと考えています。Spring Bootはフルスタックのフレームワークなので、アプリケーションを素早く作ってすぐにリリースするのには最適だと思います」

　今回のSpring Bootの導入を始め、これからも変えられるところからどんどん変えていく取り組みにチャレンジしたいと松本氏は展望を語る。

　「少し昔なら、安定性や確実性を担保するために、国内の先行事例を探して枯れた技術を使って作るのが賢明とされてきました。しかし今は、いろいろなことにどんどんチャレンジして、比較的短い期間で改善していく文化に変わりつつあります」

　そうしたトレンドの中でエンジニアも、一人ひとりが新しいことに興味を持ち、実際に体験し、それが仕事の価値として評価されるのを目指すことが重要だと訴え、松本氏はセッションを締めくくった。