ザ・エンタープライズ！Enterprise APIs Hack-Night #10レポート

6月29日、Enterprise APIs Hack-Night #10が開催されました。このコミュニティは企業におけるAPI活用を啓蒙、ナレッジをシェアしていくというものです。今回は原点回帰し、Enterprise APIがテーマとなっています。こちらはそのレポート記事になります。

富士通による社内API化の取組み by 富士通株式会社　鈴木弘樹さま

富士通ではプライベートクラウドの中でApigeeを採用しています。そしてクラウドサービスとしてAPIマネージメントを提供し、お客様含めてエコシステムを構築しています。そもそもなぜ富士通がWeb APIを推進しているか、さらに Web API推進室を立ち上げているかについて説明します。富士通では毎年、富士通サービステクノロジービジョンというビジョンペーパーを発行しています。その2014年版の中で、ハイパーコネクテッドワールドというコンセプトを掲げました。ハイパーコネクテッドワールドというのは、3年経った今では当たり前になっていますが、人や物がシームレスにネットワークに繋がっていく世界であり、それを富士通が影ながら支えていくという考えになります。この時、つなげていくためにはWeb APIが当然ながら存在しますので、Web API推進室が中心になって進めているところになります。まずどう進めていくかが問題でした。我々が採用したいのはApigeeのユーザ事例としても挙がっているAT&T社のやり方に沿うという方法でした。彼らが最初に行ったのは、社内システムをAPIでつないでいくというもので、これをトップダウンで推し進めたのです。我々も同じように社長直下の組織として、Web API化を推し進めていきました。次のステップはWeb APIの公開です。これは富士通自身はもとより、お客様にもWeb APIを公開してもらいました。そして相互のシステムを接続することでエコシステムを構築していきました。我々はSIerなので、自分たちですべて開発するという選択肢もありましたが、Apigeeを採用しています。実際、これは苦渋の決断でした。決め手になったのは開発期間で、長い時間をかけられなかったということです。現在社内にAPIポータルが整備されています。Web APIの仕様が書かれていたり、テストでAPIが実行できるようになっています。一つ一つのWeb APIは管理部署が異なりますので、このポータル上で申請をしてキーを払い出してもらう仕組みになっています。

事例について

ここから幾つか事例を紹介します。まずサポートシステムについてです。富士通は長い歴史の中で様々なハードウェアやソフトウェアを販売してきました。そのため、サポート部隊が多数あり、それぞれ別なシステムが作られてきました。例えばサーバを10台購入してもらっているとして、すべてサポートに入るとは限りません。その内の半分だけといった場合もあります。そうした際、現場のエンジニアがタブレットなどを使ってライセンス状況などをその場で確認したいというニーズがありました。既存システムを変更するのはほぼ不可能でした。そこで各システムの情報を取りだしてAPI化し、モバイルから使えるようにしました。さらにこれは社内だけでなく、パートナー企業でも使えるようにしています。次に人事システムの例があります。これはテストだけで終わってしまった例ですが。既存システムのUI生成部分を改良してWeb APIを生成するようにしました。さらにAPIマネージメントを通じてAPIを公開しています。これによって社外からスマートフォンアプリ経由で人事、総務システムにアクセスが可能になります。ただし既存システムのUI部分に一つ一つ手を入れていくのは大変だと言うこともあり、中止となりました。社外のクラウドサービスと社内システムを連携させた例もあります。これはAPIゲートウェイの力を使っています。パブリッククラウドと連携させる場合、社外ネットワークから社内システムを呼び出す仕組みが必要になります。これはセキュリティポリシーが大きな問題になります。これは当社のセキュリティ担当者からお墨付きをもらうことで実現できました。APIゲートウェイがあることで不正なトラフィックが防げること、ログがとれるので後からの監査もできるということで了承を得られました。

課題と解決策

ただ、Web API化を進める上でシステムオーナーとの温度差が問題になっています。社内システムは大前提として稼働し続ける必要があります。何の問題もなく動いているシステムに対して手を加える判断をするのは難しいです。旧来のシステムでは連携時においてファイル転送やバッチ処理が当たり前です。Web APIを作る際にはここに手を入れないといけません。もちろん改良するには予算がかかります。しかしWeb APIを作ったとしても恩恵を受けるのはシステムオーナーではなく、その周りにいる人たちです。オーナーは評価を受けられません。この問題については幾つかの解決策を考えています。まず第一にビジネスデザインから入ると言うことです。何でもWeb APIにするのではなく、特に富士通のビジネスにとって必要な部分から開発するなら許諾を得られやすくなります。また、最近打ち出されている働き方改革という外圧に乗って人事周りのWeb API化を進めていくという方法もあります。また、Web APIを公開した際に、それを使える人がどこにいるのかという問題もあります。例えばExcelを使って売り上げ分析を行っている方に対して売り上げ管理用のWeb APIが公開されたとして、その人が開発を行える訳ではありません。その実装部分についても考えないといけないでしょう。これは簡易的なフロントエンドやアプリケーションを作りやすくする仕組みも一緒に提供すべきと考えています。技術の進歩は早く、既存のビジネスがどんどん破壊されていくという危機感を持っています。しかしそれを恐れるのではなく、私たち自身が破壊する側に回りたいという思いもあります。その一つがWeb APIです。新しいサービス、ビジネスを考える方たちはたくさんいるのですが、売り上げが立った時にその管理はどうするのかという問題があります。手作業で行うわけにはいきません。IT部門が積極的に動き、社内システムをWeb API化して推し進めていかないといけないのではないでしょうか。

API-GWを媒介としたIT資産利活用によるオペレーションコスト削減の取り組み事例紹介 by NTTコミュニケーションズ　中島博行さま

NTTコミュニケーションズではAPIゲートウェイを提供しています。今回はそのAPIゲートウェイを使った事例について紹介します。SO（サービスオーダー）をAPIを使って載せ替えた事例です。なお、SOというのはNTT用語で、発注された内容を各システムにデータ登録し、ステータスに応じてワークフローが進んでいく一連の流れになります。例えば以下のようになります。 - お客様からサービスの発注をもらう - オーダー受付システムに受注情報を追加 - 契約管理システムに情報連携 - 対象サービスをセットアップ - 関連した案内メールを出すさらに各システムでは細かいタスクがあります。 SOは元々手作業で行っていましたが、自動化システムが導入されました。しかしこのシステムは年間数千万円の運用コストがかかっており、2016年度末で廃止が決まりました。問題は廃止後どうするかです。また手作業に戻るのか、はたまた自分たちでイチから作るのかといった相談を受けるようになりました。既存のシステムはオーダー受付システムから受注情報を取得し、すべて自動化していました。契約管理、開通案内は独立システムがあり、その代替システムを同じように束ねられれば自動化できるのではないかと考えました。幸い、APIゲートウェイには複数のAPIをまとめてマッシュアップし、一つの新しいAPIにする機能があります。

プロジェクトの推移

ここからプロジェクトがはじまりました。まず、新SOシステムはまるっとAPIゲートウェイに変更することにしました。次に社内システムのAPIについて調査しました。調べてみた結果、意外とAPIは存在していることが分かりました。しかしインタフェースは統一されておらず、SMTPすら存在していました。幸い、APIゲートウェイにはプラグインでSMTPを呼び出したりすることもできます。なお、プロジェクトにおいて最も時間を費やしたのは社内システムとAPIゲートウェイのネットワーク接続になります。これは申請からテスト、許可まで1〜2ヶ月かかります。今回はいの一番に申請からはじめました。様々なAPIを使う関係上、きちんと整理するためにシーケンス図を作りました。これはWebシーケンスダイアログが便利です。ここまでできあがったら、後はAPIゲートウェイの設定を行っていくだけです。これは作成したシーケンス図に沿って、XMLベースのポリシーに合わせていくだけです。どのようなリクエストが来た時に、どう変換するかを設定します。基本的に組み合わせだけでできます。このプロジェクトの効果として、年間数千万円かかっていたコストがほぼゼロになったというのが一番大きかったです。もし同じようなシステムをイチから開発していたら数億円かかっていたでしょう。さらに開発工数は私が業務の片手間で行って3ヶ月程度でした。このプロジェクトを通じた2つの気付きがあります。一つは社内システムのAPIが意外と知られていないと言うことです。APIがないと思って諦めていたことが、実は可能だったりします。二つ目は社内システムのAPIが複雑ということです。機能が長い運用の中で複雑になってしまっていたり、欲しい機能がなかったりします。日付であってもフォーマットが違うなんてこともあります。

今後について

今後、APIは誰もが作って、誰もが使うのが当たり前になっていくのではないでしょうか。サービス企画の方、営業の方でも作れるようになっていくべきです。そして、それは社内でちゃんと啓蒙して広めていく必要があります。また、開発者を意識した設計になっていなければなりません。これまでのAPIファーストからAPIネイティブへ進化するのです。今後はこのSO自動化を横展開していく予定です。モジュールを置き換えることで別なシステムに対しても同じように展開できるはずです。また、社内向けの開発者ポータルも提供していきます。

Q. どうやってAPIの開発を上長や周囲に認めてもらったのですか

私たちのチームではAPIを会社としてしっかり作っていこうという式があります。また、既存システムがすでにあって、それがなくなるとシステムをイチから作らないといけない状態でした。つまりAPI開発のメリットがしっかりと見えていた状態でした。なので効果が分かりやすく見えているならば実行に移せるのではないでしょうか。今回のように年間コストが数千万からほぼゼロになると言われて嫌がる理由はないと思います。

Q. APIゲートウェイを何か拡張しましたか？

足りない部分はJavaScriptを書いたりしたくらいで、ベースに手を入れていません。

Q. メンテナンスはどうやって行っていくのですか？

APIプロキシについては彼らがメンテナンスを行っていきます。API部分についてはワークフローも固まっていますので、一度立ち上げたものについては手を入れることは殆どないと思います。

マイクロサービス化のファーストステップ by 日本CA株式会社　加田友広さま

マイクロサービスとは限られた範囲の機能をもった独立したコンポーネントになります。それぞれのマイクロサービスはメッセージベースの通信で相互に接続できます。また、マイクロサービスアーキテクチャとはマイクロサービスの特徴を有し、高度に自動化された進化型のソフトウェア、システム開発手法、スタイルのことを言います。元々AmazonやNetflixといったビジネススピードの速い企業の考え出した、スピード感ある開発スタイルになります。そういったIT企業のやり方には一定の設計思想があり、それを切り出したものがマイクロサービスになります。開発スピードを要求しつつ、大規模なシステムに対して安全に構築できます。特に決まったプロトコルや製品を採用するという訳ではありません。そもそも、なぜ大規模なシステムをスピーディー、かつ安全に作っていくことができないのでしょうか。それはシステムが大きくなりすぎると各機能の境界が分からなくなってしまうことが挙げられます。維持可能な状態で（部分的に）リプレース可能となるシステムはどのように作れば良いのか、その答えがマイクロサービスになります。特徴としては、 - アプリケーションサイズが小さい - Web APIで通信する - コンテキスト、ドメインドリブンデザインの考え方業務範囲をベースにアプリケーションの枠組みを作る - 自主的に開発される DevOps的な考え方 - 独立してデプロイできる - 集中管理はしない - ビルドとリリースは自動化されているなどが挙げられます。モノリシックなシステムとマイクロサービスの比較として、モノリシックなシステムの中にある機能をコンポーネント化し、 Web APIで接続する形にすることでマイクロサービス化が実現します。

既存のシステムをAPI化するには

今、既存のシステムをAPI化したいという要望があります。例えばフィンテックです。社内システムはレガシーなシステムが多いです。インタフェースが古く、CORBAやFTPといったレガシーな技術が使われています。そのため、API化が難しい状態です。APIゲートウェイすら導入できないレベルの時はどうするかを紹介します。人目として、既存のバックエンド接続にAPIインタフェースをカスタムで付ける方法があります。既存のビジネスロジックをラッピングするだけの方法です。もう一つの方法として、SOA/APIゲートウェイのバックエンド転送機能（プロトコル変換機能）を使う方法があります。つまりファイルを取得してAPI化するといった方法です。これはどれくらいカスタマイズできるのか確認する必要があります。最近はバックエンドのコネクタが充実しているのですが、ライセンスが高いです。オープンソースのものもありますが、細かい部分の作り込みが発生する分、開発工数が大きくなってしまいます。最後の方法として、スクレイピングを使うこともできます。APIゲートウェイが通常のブラウザがアクセスしているかのように振る舞うのです。リクエストを解析しないといけないので大変であったり、元々のHTML構造が変わってしまうと動かなくなってしまうという問題があります。ただ、お問い合わせも多いです。

マイクロサービスのファーストステップ

ここからマイクロサービスを実践していくための方法を紹介します。まずデータセントリックとケータビリティセントリックという考え他について紹介します。データセントリックはアプリケーションを作る際に、まずデータ設計を行う考え方です。私としてはデータ構造ではなく、アプリケーションが動くためにはどういった機能が必要なのかというケータビリティセントリックの方が良いと考えています。これはドメインドリブンに近い考え方だと思います。データセントリックでは機能によってデータの共有が発生してしまい、部分的なリプレースがしづらくなります。また、データベースのアップグレードしたい、ドライバをアップデートしたいといった時に別なシステムにも影響を及ぼす可能性があります。ケータビリティセントリックは個々のシステムはデータに対して疎結合になります。レスポンスさえ変わらないならば、データベースのバージョンや種類は一切気にしなくて良くなります。現在のマイクロサービスにおけるデータの持ち方は、サービス毎にデータベースが独立して存在します。この場合、別なサービスが既存データベースにアクセスしたい場合はどうしたら良いでしょうか。データベースをレプリケーションするのは良くないでしょう。そこでデータベースのアクセスレイヤーもデータAPIとして疎結合にするのが良いのではないかと思います。新しいサービスができた時にもWeb API経由でアクセスすれば良いだけです。新しいビジネス要求に応えられない時にマイクロサービス側を変えたり、別なマイクロサービスを立てないといけない訳ですが、データAPI化すればデータアクセスが容易になるはずです。

そこでモノリシックなシステムからマイクロサービスへの移行についてです。まずロジックとデータベースを切り離します。その上でロジックをマイクロサービスに転換します。この時、各レイヤー層をWeb API化することでマイクロサービス化が実現できます。各デバイスやチャネルに対するデータ変換（JSONやXMLなど）についてはAPIゲートウェイが使えるでしょう。

この後、懇親会が開催されました。今回から勉強会と懇親会部分を分けたことで、より密の高い会話が行われていました。そして懇親会中にはOracleの生駒さんがLTを行いました。 Oracle API Managementは買収ではなくOracle自ら開始したサービスになります。元々Oracleはデータベースの企業として知られていますが、今はクラウドに移ってきています。その一翼を担うのがAPIになります。社内でもIoTやAPIの空前のブームとなっています。こんな動画も作っています。

事例としてはデンバーの交通系企業での導入があります。今、電車がどこにあるかや遅延しているかどうかといった情報をAPIで提供しています。 API関連としてはApiaryという企業を買収しています。これはAPIの設計を行うサービスで、無償サービスも提供しています。MicrosoftやGoProといった企業も利用しています。