企業向けマイクロサービスのガイドラインが不足している|その課題克服へ向けたWGの活動テーマと実践 ~TEC-JのWGメンバーを訪ねて❹

日本IBMで金融・保険企業の基幹再構築プロジェクトなどに携わる中谷純人氏は、「レガシーシステムを多く抱えるお客様向けのマイクロサービスのガイドラインが不足しています」と話す。その課題の克服へ向けたワーキンググループの活動について話をうかがった。

中谷 純人 氏

 
日本アイ・ビー・エム株式会社
IBMコンサルティング事業
ハイブリッド・クラウド・トランスフォーメーション
シニア・アーキテクト

-- 最初に経歴をお話しいただけますか。

中谷 私は2003年の入社で、今年で入社19年目となります。金融畑のプロジェクトにずっと関わってきていて、当初はメガバンク、この4~5年は保険業界のお客様も担当しています。最近の役割としては、エンタープライズ全体のアーキテクチャ策定やクラウド適用における標準を決める活動を10年近くやっています。プロジェクトの中でもガバナンスの領域の仕事ですね。そのほか、アーキテクトを育てるための研修の講師や、複雑なプロジェクトを担当するアーキテクトのアサインの調整なども担当しています。

-- 「マイクロサービス・アーキテクチャ・デザインガイド・ワーキンググループ」の設立の目的を教えてください。 

中谷 世の中にはマイクロサービスについてのガイドや書籍がそこそこあるわけですが、日本のお客様に向けて、とくにレガシーシステムを多く抱えるお客様に向けてのガイドラインが不足している、という認識から、2020年にワーキンググループ(以下、WG)を立ち上げました。2020年はガイドライン(マイクロサービス設計ガイド)の作成がメインの活動で、作成後はガイドラインを基にIBM社員を対象に研修を行っています。

-- 中谷さんの言う「日本のお客様へ向けてのガイドラインが不足している」というのは、どのような点ですか。

中谷 主には、巨大なレガシーシステムをマイクロサービス化するにはどうすればよいのか、もしくはマイクロサービスに適したアプリケーションをどのように切り出すのか、さらにサービス間のAPIをどんなふうに設定するかという、現場で実際に必要になるガイドラインですね。それと、マイクロサービスを実現する上で一番むずかしいのは、マイクロサービス間の整合性ですが、性能などの非機能要件を踏まえて整合性をどのように維持するか、そのための設計上の考慮点についての情報も不足していると感じていました。

-- WG作成の「マイクロサービス設計ガイド」はどのような内容ですか。

中谷 4章構成で、全体で170ページほどになります。すべてを一から書き起こしたのではなく、一部はクラウド開発チームが使っていたガイドラインを元にして、それをカスタマイズしつつ、相当量を書き足したという形です。メンバー9人で4カ月ほどかかりました。

「マイクロサービス設計ガイド」目次

1章  マイクロサービスの基礎知識 

◇マイクロサービスとは
 ・今求められているシステム
 ・企業本来の価値を活かすデジタル時代の次世代アーキテクチャー
 ・マイクロサービスとは

◇マイクロサービスに適合するアプリケーション
 ・マイクロサービス化検討におけるチェック項目の例

◇マイクロサービスアーキテクチャの特徴
 ・SOA vs マイクロサービスアーキテクチャ
 ・マイクロサービスアーキテクチャ9つの特徴
 ・リファレンスアーキテクチャ
 ・モノリス vs マイクロサービス
 ・モノリスからマイクロサービスへの移行パターン

◇事例
 ・マイクロサービス構築事例 – API Banking Application アセット

2章  マイクロサービスの基礎知識 

◇Microservice アーキテクチャパターン(Implementation Patterns)

◇Microservice アーキテクチャパターン(Twelve-factor App)

3章  マイクロサービスの設計手法

◇開発手法全体像
 ・マイクロサービス設計で使用する設計手法
 ・IBM Garage Method for Cloud
 ・DDD(Domain Driven Design)
 ・SOMA(Service-Oriented Modeling and Architecture)

◇マイクロサービスの識別
 ・マイクロサービスの識別
 ・トップダウン・アプローチ (ドメイン分析からのアプローチ)
 ・ボトムアップ・アプローチ (モジュール凝集度からのアプローチ)
 ・イベントによるサービス識別
 ・非機能要件の考慮
 ・サービス・ポートフォリオの定義

◇APIの識別
 ・APIの識別
 ・ドメインからのAPI識別
 ・シナリオからのAPI識別

4章  設計時の考慮点

◇サービスとデータ
 ・他マイクロサービスが保有するデータへのアクセス
 ・Command Query Responsibility Segregation(CQRS)

◇結果整合性の確保
 ・TCC(Try-Confirm/Cancel)パターン
 ・Sagaパターン
 ・リトライとべき等性

◇業務継続性
 ・サーキットブレーカー

◇API認証
 ・APIの認証
 ・OAuth2.0
 ・API認証周りの設計上の考慮点

-- たいへんな分量ですが、それだけ日本のユーザーにフィットするガイドラインがなかった、ということなのですね。

中谷 一般的にも、またIBM社内をグローバルで見ても、SoE向けのマイクロサービスのガイドラインはたくさんありますが、SoR向けのガイドラインは非常に不足しています。あるいはSoEとSoRをつなぐ部分のガイドラインですね。

ただし、マイクロサービスにすること自体がゴールではないので、マイクロサービスに“すべきところ”と“しないところ”をきちんと見極め、切り分けられることが一番大事だと思っています。マイクロサービスに向くのはこういうアプリケーションであるとか、レガシーの中から切り出すのならどこを切り出すのか、ということについての知見や、あるいは、マイクロサービスをやりたいというお客様がいても、そこはマイクロサービスにしないほうがよいということをきちんと伝えられる知識、そうした知見やスキルをIBM社員に身につけてもらいたいと思っています。私が担当したお客様の中に、SoRを一律マイクロサービスで作り直したいというご要望がとても大きなお客様がいたのですが、そのことも今回の活動につながっています。

-- レガシーシステムの中で、マイクロサービス化しやすいのはどのようなものですか。

中谷 実は「マイクロサービス設計ガイド」の中で、アプリケーションがマイクロサービスに向いているかどうかを確認するためのチェックリストを作っています。ポイントは変化の速いところで、そういう部分はSoRにも必ずあるはずです。マイクロサービスの知見がないお客様であれば、そういうところから小さく始めるほうが始めやすいのではないかと思いますね。

マイクロサービスへの移行については、一括でやる場合もあれば、少しずつ切り出していくアプローチもあります。日本のお客様の場合は圧倒的に後者ですね。

-- ユーザー企業でマイクロサービスを推進するにあたって、中谷さんが課題と思うのはどのような点ですか。

中谷 お客様の技術ベースがホスト(メインフレーム)であることが多いので、どうしてもホスト的な考え方をしてしまうという点でしょうか。たとえばAPIといっても、昔で言う電文のようなインターフェースを作ってしまったり、コンポーネントの中身も昔ながらの設計をしがちです。そこをマイクロサービスの考え方にどのようにチェンジするか、そのマインドチェンジが一番むずかしいところで、課題と捉えています。マネージャーたちの目指すところははっきりしているのですが、現場の人たちがそこまでついて来れていないという印象ですね。

-- いっそ、マイクロサービスを肌感覚で身につけている若い人たちとやったほうが早いと思ったりしませんか。

中谷 おそらく、小さなシステムを作るのならそうした新しい人たちだけでできると思うのですが、大型のエンタープライズシステムは、従来からの考え方をもっている人を含めて取り組まないと進まないだろうと思います。システムとはそもそもどういうものか、データの整合性はどこまできっちり取るべきか、ということを理解している人たちですね。そういう人たちが中軸となって初めて、エンタープライズシステムのマイクロサービス化は進んでいくのだろうと思います。

-- 研修ではどのようなことをやっているのでしょうか。

中谷 研修は3カ月に1回のペースで、1回は10時間、1日5時間のコースを2日連続で行っています。テキストは「マイクロサービス設計ガイド」で、座学を半分、残り半分を手を動かしてもらうワークショップとしています。

ワークショップの題材は、ネットによくある宿泊予約サイトです。それをマイクロサービスで構築することを練習してもらいます。「マイクロサービス設計ガイド」でWeb購買システムのマイクロサービス化を解説しているので、ワークショップはその応用編という感じです。

-- ワークショップでは具体的にどのようなことをやるのですか。

中谷 まずドメイン分析によりドメインを分割するところから始めてもらい、各ドメインのコンテキストを定義して、マイクロサービスの候補を識別します。次にマイクロサービスが持つAPIをトップダウンとボトムアップの両方のアプローチから識別し、さらにサービスとサービスをどのように連携させるのかも検討します。最後に非機能要件を考慮して、1つのマイクロサービスを必要に応じて小さなサービスに分割したり、逆に複数のサービスを1つに結合したりするのが大まかな流れです。

-- 2021年のWGのテーマとして、「コンテンツの更新」と「研修内容の見直し」を挙げていますね。

中谷 「マイクロサービス設計ガイド」を研修で使ってみて、マイクロサービスの切り出しのところがやや漠然としていてわかりづらいという声があったので、そのあたりをレベルアップしました。切り出し方のところはドメイン駆動開発の手法を用いていますが、書籍を参考に記述していた部分を自分たちの言葉に置き換えたり、IBMのメソドロジーとのリンクを強化しています。

それとサービス間の整合性の維持方法ですね。もう少し具体的に説明してほしいという声が多かったので、そこも強化しました。たとえば3つのサービスを利用しているアプリケーションで、2つは成功したけど3つ目が失敗したら、2つのサービスをどのように戻すのか。エンタープライズのアプリケーションでは必ず出てくる問題ですが、マイクロサービスになるとより難しくなるので、説明を強化しています。

そのほかには認証があります。認証の領域は変化が大きいのと、マイクロサービス自体の要素ではないため、すべてを取り込めたわけではありませんが、OIDC(OpenID Connect)に触れたり、マイクロサービスでよく使用されるAPI認証をどのように実現するのかについて、より詳しい説明を加えています。

全体としては、「マイクロサービス設計ガイド」はもともと網羅的な構成なので、部分的なマイナーチェンジになりました。

-- 研修についてはどのような見直しを行ったのですか。

中谷 大きくは変えていませんが、マイクロサービスを切り出した後にAPIを識別するところのやり方がわかりづらいという声があったので、少し見直しました。CRUDに相当するようなAPIであればそれほど込み入った説明はいらないのですが、ビジネスで使われるAPIとはどのようなものか、とか、業務寄りのAPIの識別方法について詳しく触れるようにしました。

-- そもそもの話になりますが、マイクロサービスを適用するシステムの開発は、シーケンスを書いてドメインを決めて、という流れが一般的なのでしょうか。

中谷 逆にAPIから作っていくというアプローチもあると思います。「Twelve-Factor App」などで述べられている“APIファースト”ですね。APIを先に識別していくと、何を実現するサービスなのかがわかりやすいという特徴があります。そのボトムアップ的なアプローチに対して、研修ではドメインから定義していくトップダウン的なアプローチでやっています。

-- 1回の研修には何名くらい参加するのですか。

中谷 30名前後といったところでしょうか。

-- 対象者として「アプリケーション開発経験のあるBand7以上の技術者」とし、「コンポーネント設計やサービス設計の経験があることが望ましい」とあります。

中谷 入社して10年くらいの技術者で、アプリケーション開発を一通り経験しているような人に受講してもらいたいと思っています。

-- 2022年はどのようなことを計画していますか。

中谷 2021年の研修の結果次第ですが、現在の研修自体はエントリーレベルなので、よりアドバンストなコースを作ろうという意見も出ています。より大きなエンタープライズアプリケーションを対象にしたり、Kubernetesやコンテナなど基盤寄りの話を充実させるなどですね。そのへんはこれから議論するところです。簡単な題材だとエンタープライズのレベルにならないので、サンプルを難しくして、モノリスからマイクロサービスを切り出すにはどのようにしたらいいのか、より実践的で具体的なものを作りたいと思っています。

-- 中谷さんご自身は、何に関心をもっていますか。

中谷 コンテナのオーケストレーション技術がどんどん進化しているので、それがマイクロサービスとどのように関係するのか、継続的に追うようにしています。オーケストレーション技術とマイクロサービスは、切っても切れない関係ですね。コンテナやオーケストレーションは基盤の領域だからアプリケーションをやっている人間には関係ない、とは言えない時代になってきていると感じています。

中谷 純人 氏

日本アイ・ビー・エム株式会社
IBMコンサルティング事業
ハイブリッド・クラウド・トランスフォーメーション
シニア・アーキテクト

2003年に日本IBMソリューションサービス(現日本IBMデジタルサービス株式会社)入社、2013年に日本IBMに転籍。メガバンクや保険会社といった金融機関におけるシステム統合・基幹系再構築プロジェクトに多く従事。近年はエンタープライズ・アーキテクチャやモダナイゼーション・ロードマップの策定、アーキテクチャ・ガバナンスなど企業システム全体を俯瞰するアーキテクトとして活動するかたわら、クラウド・アーキテクチャのIBM社内講師も務める。

*本記事は話し手個人の見解であり、IBMの立場、戦略、意見を代表するものではありません。


当サイトでは、TEC-Jメンバーによる技術解説・コラムなどを掲載しています。

TEC-J技術記事https://www.imagazine.co.jp/tec-j/

[i Magazine・IS magazine]

More Posts