革命のブログ革命のブログフレボワークスの社員がブログを通じて情報発信します。2018-11-16マイクロサービス化に悩んでる人へマイクロサービスどうも、小野です。マイクロサービスの有効性や複雑性など再認識させられました。以下のスライドがとても参考になりました。SUZUKIwww.slideshare.net今はバスワードとも言える「マイクロサービス」。マイクロサービスとよく比較されるものとして、モノリシックというアーキテクチャがあります。モノリシックは1枚岩と表現されるとおり、1つの巨大なシステム(サービス)のことです。管理対象は1つなので、管理は楽そうではありますが、以下のようなデメリットが挙げられます。プログラム修正時の影響範囲の把握が難しいテストを含むビルドに時間がかかるこれは最終的にリリースサイクルのスピードに関わってきます。これらを解決するために考えられたのが、マイクロサービスです。私もマイクロサービスについて勉強し、導入を検討しましたが、結局断念しました。断念した理由ですが、主に以下の3つが挙げられます。実装コストをなるべく抑え、品質を重視する必要があったため、断念せざるを得ませんでした。その上、人が全然足りず、マイクロサービスをやっていくのは自分の首を締めるだけでした。本記事ではマイクロサービスの導入によって、どこまでのメリットが得られるか考えながら読んでいただきたいです。マイクロサービスのメリット新しい技術を導入する際、メリットとデメリットを確認すると思います。ここで、まずはマイクロサービスのメリットについて述べていきたいと思います。技術異質性サービスごとに異なった技術での開発が可能になります。チームごとに得意な技術、または新しい技術で挑戦できます。障害が起きても、問題のあるサービスを切り離すことで、他のサービスを稼働し続けられます。その間は問題のあるサービスに対する処理(リクエストなど)は動作しません。スケーリングサービス単位でのスケールが可能になります。柔軟に効率よくスケールできます。そのため、モノリシックに比べ、コスト効率が良くなる場合があります。デプロイの容易性サービス単位でのデプロイが可能になり、システム全体としての影響を最小限に抑えられます。他のサービスとは独立しているため、迅速なデプロイが可能です。マイクロサービスは諸刃の剣マイクロサービス導入で得られるメリットはありますが、一歩間違えると「諸刃の剣」と化します。その理由を前項で挙げたメリットと比較してみていきます。技術異質性サービスによって最適な技術が必要なのは重要ですが、本当に必要か疑問に思います。逆に技術を統一化することで、モジュールの再利用性も高まるのではないでしょうか。問題があるサービスがアカウント(ユーザ)などのシステム全体の基盤となるサービスの場合、全体に影響が及ぶことになります。あと、原因の追求が困難になることもあります。サービス内部ではなく、サービス間通信のネットワーク障害や、マシンの障害なども関わってきます。サービスごとのログをfluentdなどを使って集約した状態で管理しておかないと、各サービスのログを確認する必要が出てきます。無駄なコストがかかってしまいます。サービスごとにリポジトリを分ける必要があります。サービスごとにバージョンを意識する必要があります。ここではデータベース分割(ドメインの分割)による問題について考えてみます。データベース分割(ドメインの分割)による問題N+1問題とくに個人的に難しいのはデータベース分割(ドメインの分割)によるデータの扱い方です。基本的にサービスによって管理するテーブルは分かれますので、モノリシックでは、データを取得する際に結合(JOIN)で取得できていたものが、マイクロサービスでは、親(結合元)を取得し、付随するサービスのデータを取得するために、親のレコード分のクエリを実行するN+1問題が発生したりします。N+1問題については解決する方法はありますが、クエリの煩雑化やパフォーマンスなど別の問題が出てきます。A口座からB口座へ振り込みをしたときの例で考えてみます。登場人物としては、振込サービス、出金サービス、入金サービスがあるとします。振り込みを行った際の主な処理は以下のとおりです。振込サービスが入金サービスを呼び出し、B口座に100万円を入金ここで、2.を行うときに失敗した場合はどうなるでしょうか。マイクロサービスの場合はどうでしょう。トランザクション境界が別なので、モノリシックと同様の実装だと、1.のみコミットされることとなり、データの不整合が発生します。振込サービスが2.でのエラーを検知した際、1.の処理を戻すトランザクションを発行する必要があります。100万円を出金したレコードを削除します。あとは、分散トランザクションを利用する方法がありますが、実装がより複雑になります。サービス間でのデータの受け渡しサービス間でのデータの受け渡しには多くの場合HTTPを利用することになります。内部のネットワークに限るのですが、ネットワークを介すということはネットワーク障害時のことも考慮する必要があります。通信間で考慮すべきことにはリトライ処理や、タイムアウト時の処理中断などがあります。データベースから直接取得したほうが、実装が単純な上、パフォーマンスも良いです。そこはビジネス要件を考慮した上でのトレードオフになるのではないでしょうか。ここで、以下のチェックリストをやってみてください。現在、モノリシックなシステムがあるリリースサイクルの早く回したいシステムの規模に対するリソースが足りているマイクロサービスを熟知している人がいる、またはメンバー全員が意欲があるCI/CDなど自動化の仕組みがある全てチェックの場合はマイクロサービスの導入を検討してもいいと思います。逆に未チェックが1つでもあった場合は、異なるアプローチがないか検討してください。さいごにマイクロサービスというのはあくまでもアーキテクチャの方針であり、実装方法は十人十色です。マイクロサービス導入を検討するべきだと思います。今すぐにマイクロサービスをやりたい人は、小さいなところから始めるようにしてください。Actionsへ移行を検討している話どうも、小野です。2019に参加してきましたどうも、小野です。2019/10/3~2019/10/4の2日間で開催された...2019-09-24セッション管理方式のお話どうも、小野です。9引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。