マイクロサービスによるAPI構築のいろは

近年、クラウド・アジャイル・DevOpsなど、生産技術は目覚しい進化を遂げており、これまでの開発スタイルで当たり前とされていたことが、当たり前でなくなってきています。

例えば、クラウドを利用すれば、サーバを自社のデータセンターで抱える必要がなくなります。アジャイルの思想では、ウォーターフォール型とは異なり、顧客にとっての価値(仕様・スコープ)が常に変動する前提に立って開発を進めます。DevOpsの考え方を表現した、Amazon.com(AWS)のWerner Vogels CTOの言葉「You Build It, You Run It」は、「コードを作った人が運用の責任も持つ」ことを示しており、開発者の価値観が変わるきっかけとなりました。

APIエコノミーは、こうした変化や新たな技術を取り込むかたちで実現されています。

モノリスからマイクロサービスへ

生産技術の中でも、APIエコノミーを実現可能にする要因として、マイクロサービスが挙げられます。

マイクロサービスの特徴は、システム全体を小さな粒度のサービスに分けて構築する点にあります。その際、サービス間の入出力はAPIとして定義します。

APIエコノミーの考え方と同様、連携の対象はシステム内外を問いませんが、マイクロサービスが生産技術を中核に置いているのに対し、APIエコノミーはより他システムや他のビジネスを利用していく考え方が中心にあります。

マイクロサービスによる開発スタイルに対し、従来型の開発スタイルをモノリス(Monolith)と呼びます。モノリスとは一枚岩の意で、システムを単一のアプリケーションで構築します。

一枚岩のアプリケーションは、フロントの画面とバックエンドのプログラムなどが密結合であるため変更容易性が下がり、「ビジネスのスピード」を下げる要因となっていました。システムが巨大化すればするほど、全体を把握するのが困難となるのは言うまでもありませんが、各層が密結合していために、影響範囲を見切るのが難しかったのです。

また、一度アプリケーションをリリースしようとした際、単体テストや結合テストといったテスト対象範囲が一枚岩の単位となります。JUnitやSeleniumといった自動テストをフル活用したアプリケーションのビルドプロセスを導入していたとしても、アプリケーションの規模によっては所要時間が数時間～数日になることもあります。

マイクロサービスの単位をビジネスレベルにし、APIとして公開していくことで、開発における再利用がより進み、高頻度なリリースが可能となるため、ビジネススピードの向上に寄与することになります。

マイクロサービスは、クラウドやDevOpsを構成するCI(Continuous Integration) / CD(Continuous Delivery)技術など、開発プロセスを構成する5つのフェーズ「環境構築」「開発」「ビルド」「デプロイメント」「環境変更」でさまざまな生産技術を利用しています。

マイクロサービスの詳細について詳しく理解したい方は拙著「今さら聞けないマイクロサービス」をご参照ください。APIエコノミー時代において、マイクロサービスアーキテクチャをベースとして開発を行う場合は、これらの生産技術をいかにうまく使っていくかがポイントとなります。

表 : フェーズ別のツール/手法

No	領域名	対象フェーズ	利用技術例
1	ソースコード自動生成	開発(設計・実装)	Eclipse、TERASOLUNA ViSC
2	テスト自動化	単体テスト	JUnit、Jasmine、JsTestDriver
		機能テスト	Selenium、Selenide
		パフォーマンステスト	Apache JMeter
3	デプロイ自動化 (DevOps、CI/CD)	開発環境	Jenkins、Gradle、Maven、Capistrano、Fabric
		ステージング環境
		本番環境
4	基盤自動化 (Infrastructure as Code)	環境構築・環境変更	構築:SDN、Chef、Puppet テスト:ServerSpec 概念:Immutable Infrastructure 仮想化:Docker

API Gatewayパターンを用いたシステムアーキテクチャ

業務要件を実現するためのソフトウェアの実装方法によって、生産性やメンテンス性は大きく変動します。この課題を解決する手段の一つがデザインパターンです。GoF(Gang of Four)の23のデザインパターンなどが有名でしょう。

マイクロサービスを実現するシステムアーキテクチャとしては、特定のサービスの故障が連鎖し、システム全体の故障へと波及するのを防ぐ「Circuit Breaker」パターンなどが存在します 。

APIエコノミーでは複数のAPIを組み合わせてシステムを構築します。そのため、APIの呼び分けであったり、複数APIコールによるネットワーク帯域の圧迫であったりの課題が生まれます。

そこで、API Gatewayパターンと呼ばれる、複数のサービスを呼び出すためのGatewayサービスを構築する手法がベストプラクティスとなりつつあります。例えば、「製品情報」「レコメンド」「レビュー」といったAPIがあった場合に、それらを個別に呼び出すのではなく、一度の「API Gateway」呼び出しで複数のサービスを起動し、結果を集約した画面を取得することができます。これによりネットワーク帯域の圧迫を防ぎます。

サーバレスアーキテクチャとAPIエコノミーの親和性

SMACのCの要素であるクラウド技術は、年々進化を遂げており、さまざまなクラウド技術の組み合わせによるシステムアーキテクチャを簡単に定義するAWS Elastic Beanstalkや、そもそもシステムアーキテクチャを意識せず、CPU/メモリ/ディスクといったリソースのみを定義する、AWS Lambdaなどのサーバレスアーキテクチャが出てきています。

システムへの負荷が高まった際、CPU/メモリ/ディスクが自動的に追加される「Auto Scaling」が用いられることが多くなっています。このように、「蛇口をひねるとCPUリソースが使える」ような時代が現実化しています。こういったクラウドを前提とする開発スタイルをクラウドネイティブと呼びます。

ChefやPuppetに代表される基盤自動構築の技術が、上記を実現するための下支えとなっており、特定の設定をすると自動で基盤が出来上がるようなレベルまで達しつつあり、Immutable Infrastructureと呼ばれる、基盤を必要な時に作り、使い終わったら捨てるという考え方が出てきています。

APIエコノミーにおいては、他社からビジネスが呼び出されることも想定しなければなりません。したがって、必要な時だけ環境が構築され、CPU実行時間で課金されるモデルの方が、アイドル時間中に無駄なコストが生じることなく、急なアクセス集中にも対応できるため、親和性が高いと言えます。

*　　*　　*

マイクロサービスを初めとするAPIエコノミーを構築するための生産技術が出揃ってきています。今回はその例として、表「フェーズ別のツール/手法」にて示したような4つの自動化技術や、API Gatewayパターン・Circuit Breakerパターンなどのデザインパターンなどを紹介しました。

SMACのCの要素であるクラウドでは、サーバレスアーキテクチャ・Auto Scalingなどの技術が出てきており、残りのSMAを下支えしています。

次回は具体的にAPIを構築する手順を紹介し、実際にAPIエコノミーに触れていただきます。