はじめに

先日担当した案件でマイクロサービスアーキテクチャを使用する機会があったので、そのときのファーストインプレッションを皆さんにご紹介したいと思います。

マイクロサービスアーキテクチャとはなんですか？

マイクロサービスアーキテクチャは最近聞くようになった言葉で、LINEやクックパッドなどの企業が採用したり、アーキテクチャとして「変更に強い」、「リリースが早い」と言ったことを耳にします。

新しい言葉のようですが、実態としてはコンピュータサービスの黎明期から存在する歴史ある開発手法である気がします。

例えば電子メールの仕組みを単純に考えると送信と受信は完全に分離されています。

1.送信者は送信先のメールサーバにメールを送る
2.受信者はメールサーバからメールを取得する

メールの送信サービス、受信サービスの2つのサービスで電子メールの送受信が関わっていることがわかります。
大雑把ですがマイクロサービスではこのように複数の小さなサービスを連携させて、大きなサービスをユーザに提供しようという考え方です。
バッチ処理でタスクが小さなステップから成り立っているのと同じように考えても、間違ってない気もします。

なにが変わったの？

一般的なWebアプリケーションの場合、MVCモデルを元にした3階層の構成になると思います。
マイクロサービスで大きく変わるのが、モデル層、ビジネスロジック層とも呼ばれる業務処理を行う層が、ネットワーク越しにアクセス可能な独立したサービスとして稼働していることでしょう。
このため業務処理部分の参照先を変更したり、複数構成にして冗長性を確保したりと言ったことが容易に行なえます。

マイクロサービスアーキテクチャを使用した感想

サーバサイドのビジネスロジック部分、マイクロサービスではドメインとも呼ばれる開発しました。
アプリケーションをサービス単位として独立して製造するので、製造範囲に無関係なサービスに関しては完全に無視できる、いわゆる疎結合としてサービスを製造できるのは非常に楽な点でした。
他のサービスの仕様変更などの影響を受けにくいということで、これは開発を進める上で大きなメリットだと感じました。

まとめ

アプリケーションとしては高度なネットワーク・インフラの上に成り立っているアーキテクチャなので、なにをするにもネットワークの問題も考慮しないといけなくはなりますが、「分割して統治せよ」の言葉通りに、現代の複雑な機能を持つアプリケーションを小さな単位で開発できるのは非常に楽なものです。

機能が疎結合というこは開発チームの人間関係も疎結合になりやすいのではないのかという問題もありそうです。

システム開発手法としては非常にまっとうなものなので、マイクロサービスアーキテクチャという言葉はなくなっても、開発手法としては長く続いていくものではないかという気がしています。

エンジニア想いの環境でJavaやPHPにチャレンジしたいエンジニア募集！