tambourine.inc で 技術顧問的なオシゴトをさせてもらってます。
よろしくお願いします。
本日、セールスフォースワールドツアー東京でもお話させていただきましたが、
Herokuとマイクロサービスに関する運用事例を紹介させていただきます。
背景
株式会社 tambourine ではSalesforceを用いた受託開発の案件を多数手がけています。
バックエンドに関する問題は概ねSalesforceのソリューションで事足るのですが、
顧客の基幹との連携、フロントエンドの実装などにはどうしてもスクラッチでの開発が欠かせません。
高速な開発フローの確立のためにも、ユーザ管理に関する統一的なインターフェイスが不可欠でした。
TAMOPACK
TAMOPACKという名称で試験的にスタートした統合インターフェイスの開発は、
単純にSalesforceとフロントエンドの連携を行うためのPHPアプリケーション構成を想定して始まったものでしたが、
変に懲りすぎた結果 Composerで導入可能なPHPライブラリとしてリリースされました。
(現在は運用上の都合も考え、git subtreeを用いた構成に移行しています。)
TAMOPACKはユーザ管理に関するHTTPインターフェイスの提供を軸に、
DIを用いたユーザ管理/セッション/メール送信コンポーネント、
及びイベントフックの機能を提供するライブラリとして制作されました。
設計的な用語を用いていうとMVCのCのみを提供するレイヤ + DIで差し替え可能なModel群という構成です。
TAMOPACKの概念自体は比較的単純なものでしたが、これの導入によって以下様々なメリットが生まれました。
- 一般的なユーザ管理に関するアプリケーションの開発スピードが大幅に向上
- フロントとバックのコミュニケーションプロトコルである API仕様書 の共通化により、開発効率が大幅にアップ
- フロント側でも決められた形式のAPIをコールすることにより、ライブラリとしての共通資産が生まれる。
- 自動テストによるユーザ管理部に関する形式的なテスト工数が大幅に削減される。
「DIで切り離し可能な、HTTPインターフェイスのみの実装」という試みは、
当初想定されていた「Salesforceとの連携案件」以外への転用も可能にし、
社内で統一的なユーザ管理API仕様書が構築されたのは、実に大きなメリットだと思います。
Next Stage
Heroku Connect の登場により状況はさらに進展します。
Heroku Connect は 1日目でも紹介頂いている、Salesforceのデータ群とHeroku Postgressを連携するためのソリューションです。
試してみるとなかなかに便利なもので、感動を覚えるサービスなのですが、
実際に設計に落としこむとなると、「双方向同期」というやつの取り扱いになかなか手こずります。
特にEC-CUBEやWordpressなどのパッケージと連携する際には、なかなかつらいものがあります。
だいたいこの辺りから、TAMOPACKは
「統一されたHTTPインターフェイス」から
「ユーザ管理用のアプリケーションプラットフォーム」へと役割を変えようとしていきます。
ユーザ管理プラットフォームとしてのTAMOPACK
Heroku Connect と 既存アプリケーションの統合が難しいなら、TAMOPACKで橋渡しをすればいいじゃない？
というところからTAMOPACKの新しい道は生まれました。
Heroku Connect を TAMOPACKで連携して、外部アプリケーションをTAMOPACK経由でつなげていくことで、
ユーザ管理に関する責務をTAMOPACKに任せながら複数のサービスを連携させることが可能になります。
EC POINT BLOG といった各種サービスをSalesforceに連携して…という構成を考えると、
従来なら巨大なフルスクラッチ案件が上がってきたものが、
SalesforceとTAMOPACKのユーザ管理を軸にした、複数の小規模なサービス群の構成で実現可能になるわけです。
マイクロサービスの現実と課題
複数の小規模なサービス群構成、いわゆるマイクロサービスは、柔軟なアプリケーション構成を実現しますが、
管理コストの問題、アプリケーション群の複雑性という課題をはらんでいます。
管理コストの問題
インフラが分散したとしても、Heroku上の開発を行う上では特に困った事はありませんでした。
Heroku の ORGANIZATIONS を導入することで 分散したdynoも案件ごとに整理することができ、
また案件内でのサービスグループもpipelineの導入で簡単に整理することができます。
正直な話、流行りのlambdaとかを使ったマイクロサービス運用は、ちょっと運用のフローが見えて来なかったのですが、
Herokuのdashuboardくらい整理されたものがあれば「行ける!!」という感触をつかめました。
ソースの管理に関しても、それぞれのサービスグループがgithubと連携することで、
インフラとソースのひも付けもdashbord上で可視化され、また開発者がherokuのdyno構成を意識すること無く、
github上で開発/試験までのやり取りを済ますことができるようになりました。
糞面倒なインフラ構成仕様書とかインフラ群のアクセス管理みたいなものを全く意識しなくていいというのはホントに助かります。
合わせて共通コードの管理にはgit subtreeを用いて、よりフランクにfixできるように改善しました。
TAMOPACK自体のメンテナがそんなに多数いるわけではないのですが、phpでvendor以下に潜って…と言うのは何かとホントに面倒です。
(合わせて言うならHerokuにおけるプライベートリポジトリの依存解決とか…)
アプリケーション群の複雑性
TAMOPACKにおけるアプリケーション間の連携は、「ユーザ管理」という軸で限定/一貫されているため、
各種サービス毎の複雑性はむしろ下がった、という印象です。
EC CUBEやWordpressなどの外部パッケージも、
ユーザ管理に関する責務をTAMOPACKに投げるための、いわゆるデリゲート的なAPIを数本用意するだけで、
比較的簡単にサービス群と連携することが可能になりました。
マイクロサービスとHeroku
今回 Heroku Connect をきっかけに マイクロサービス群の技術設計に携わり、
気付く点は色々と多かったです。
破綻しないマイクロサービス群構築のために重要なポイントは
- サービス間の交流内容をわかりやすく
- サービスごとの責務を明確に
- インフラの管理をわかりやすく
という３点に尽きると思います。まぁソースコードのモジュール化とほぼ似たような注意概念を
アプリケーションのレイヤに落としこむ…程度の話ですね。
その上でHerokuは3点目の「わかりやすいインフラ」構成というのを提供してくれます。
Pipeline や private space、deploy支援や各種addons など紹介するときりがないのですが、
インフラに関する柔軟な機能を洗練されたGUIのダッシュボードから利用できるというのは、
運用面から見ても他に無い素晴らしいサービスだと考えています。
「gitでpushするとデプロイできる」というプロビジョニングの手軽さ、ばかりが注目されるHerokuですが、
プロビジョニングの先にある開発フローや運用面などにも目を向けてみると、
きっともっとHerokuのことが好きになれると思います。