どうもこんにちは。
ディベロップグループ（開発部）に所属している井上寛基と申します。
最近(2019/7)は上流の設計フェーズを担当させていただいておりますが、基本は実装フェーズでプログラムを書いてます。
弊社では基幹業務システムに外部パッケージソフトウェアを利用しているのですが、以下のような声が現場の利用者から出ていました。
信頼性、保守性が低い
事業に合わせて迅速に変更出来ない
挙動が重くサクサク動かない
私たちも現行のシステムは業務とマッチしておらず改修しても全ての課題を解決できないという問題は以前から感じていました。
そこで、フルスクラッチでのマイクロサービス開発に踏み切りました。
ありがたいことに社外の多くの方から開発中の マイクロサービスについて詳しく知りたいという、お言葉を頂きました。
そこで、私が業務経験から学ばさせていただいた、マイクロサービスの基礎概要について簡易的ではありますがまとめさせて頂きました。
マイクロサービスとは
マイクロサービスを説明する前に、モノリシックスタイル（アーキテクチャ）を説明します。
マイクロサービスと対比で述べられることが多いモノリシックスタイルを理解し比較する事で、マイクロサービスのメリット、デメリットがより明確になります。
では、早速ですがモノリシックスタイルとはなんでしょうか？
モノリシックとは全ての機能が１つのシステムとして稼働するスタイルを指します。
……言葉で説明しても、難しいのでざっくりイラスト図にしてみました。
■ 画像：モノリシックスタイル
例えば、クライアントAが顧客管理システム、クライアントB予約管理システム、クライアントCが契約管理システムを利用したい場合でもモノリシックスタイルでは同じシステム上で機能を提供します。また、ストレージも同じ場所にあります。
このように目的が別々でも同じシステムで処理を行うアーキテクチャスタイルをモノリシックスタイルと言います。
一方、マイクロサービスではクライアントA、クライアントB、クライアントCの目的機能に応じてシステムを分けます。ストレージもシステム毎に分割します。
■ 画像：マイクロサービス
簡潔にまとめるとモノリシックスタイルが「単一システムで、複数の機能を提供するアーキテクチャ」、マイクロサービスが「複数の独立した機能を組み合わせることで、一つのシステムを実現するアーキテクチャ」と表す事が出来ると考えます。
モノリシックスタイルとマイクロサービスを表す言葉に「密結合なモノリシックスタイル、疎結合なマイクロサービス」があります。
この表現方法はモノリシックスタイルとマイクロサービスをうまく表している表現方法だと思います。
マイクロサービスのメリット
上記でモノリシックスタイルと比較したマイクロサービスの概要説明をいたしましたが、ビジネス視点で考えられるマイクロサービス のメリットはなんでしょうか？
柔軟な変更が可能
モノリシックスタイルで構築されたサービスを事業に合わせてスケールさせるには非常に手間がかかります。
複数の機能が密結合になっているため変更した時の影響範囲が把握し辛く、対応を誤ると思わぬバグを生む可能性が高くなり、これを防ぐには事前調査とテストに時間がかかってしまいます。
一方、マイクロサービスでは複数の機能を組み合わせて疎結合に構築しているので影響範囲を局部的に収める事が出来、調査やテストに必要な時間（コスト）を下げる事が出来ます。
よって、モノリシックスタイルと比べて柔軟な変更が期待できます。
弊社では事業の変化に合わせてシステムを変更することが多いのでマイクロサービス のメリットの一つである柔軟に変更が可能というメリットの恩恵は非常に大きいと感じています。
サービス毎に最適な技術を採用できる
モノリシックスタイルのように単一のシステムとして構築したアプリケーションの場合は技術選択の選択肢が狭まってしまいます。
一方、疎結合なマイクロサービスでは各サービス毎に独立している為、サービス毎に最適な技術を採用出来ます。
例えば、今後は画像認識機能には機械学習（ディープラーニング）を用いてより事業価値の高いシステム構築を目指していく予定です。
このように、サービス毎に必要な機能や目的に応じて最適な技術選択出来る点もマイクロサービス の利点の一つになります。
マイクロサービスのデメリット
勿論、マイクロサービス にはメリットだけではなくデメリットも存在します。
データの一貫性の保証が難しい
上記のマイクロサービス概要画像を参照しても理解できるように、マイクロサービスでは各サービス毎にデータストレージが別れています。
よって、サービスをまたぐ時のデータの一貫性を保証するには多くのスキルが必要になります。
そこで、私たちは要件定義段階で各サービスが別サービスに依存しないアーキテクチャ設計になるように十分に配慮いたしました。
この要件定義段階で要件の内容をしくじると、サービスをまたいでのデータ更新が必要になってしまい、データの一貫性を担保することが難しくなってしまいます。
オーバーヘッド（パフォーマンス）が巨大化するケースがある
クライアント側からBFFへのリクエストは一つだけの機能だったとしても、サーバーサイドで複雑な処理が必要な場合、サーバーサイドで呼ぶAPIは複数回発生する事があります。
この為、通信回数が増えオーバーヘッドが巨大化するケースがあります。
このケースをなるべく減らすために私たちは、設計フェーズからAPI処理をなるべくシンプルにするように心がけています。
〆
弊社がマイクロサービス開発をスタートした最大の理由として事業の変化に柔軟に合わせられるようなサービス（プラットフォーム）を実現させたいという気持ちがありました。
また、未経験分野でもある、マイクロサービス を0ベースから開発することでエンジニアとしての成長も期待できると考えました。
弊社ではエンジニアとしての成長を第一に考えております。
私もマイクロサービスのDB設計、API設計、BFF実装、サーバーサイド実装からテストまで幅広い実務経験を経験させていただいておりエンジニアとして成長できていると日々感じております。
エンジニアとして力をつけたい、技術的チャレンジを積極的に行う会社で仕事がしたいと考えている人には最適な環境だと日々感じています。
では、さようなら。
