こんにちは、Tatekiです。
現在私は上場企業でマイクロサービスの一部アプリケーションを担当しており、複数のアプリケーションが繋がることでエンドユーザーへのサービス提供が実現しています。
海外拠点 (オフショア) を含めて4か国10以上のアプリケーションからなるマイクロサービスは、マイクロサービスならではの悩みに直面します。
そこで今回はマイクロサービスではどのような問題が起こりやすいのか？と、どうのように対策するべきか？について書きたいと思います。
指揮系統が違うと、作戦は失敗しやすい
一つ目の問題は、各アプリケーションの指揮系統が違う為に協業が上手くいかず、スケジュールが遅れたり、要件間違いによりインシデントになるケースです。
大きな視点では同じ方向に向かっていても、部署同士の仲が悪い為に作戦が失敗することは珍しいことではありません。
事例を上げると、旧日本帝国の陸軍と海軍はライバル関係にありました。太平洋戦争時に東アジアから東南アジアへ侵出した陸軍が戦地の拡大とともに多くの予算を獲得しるようになると、相対的に割り当てられる予算が減ることに焦った海軍は自身の予算を確保する為、積極的な作戦: 真珠湾の攻撃に向かったとも言われています（一つの要因であって、これだけが原因ではありません）。
同様に、ドイツでも旧第三帝国と言われるナチス時代に、もともと軍役を担っていた国防軍とナチスの私兵であるナチス親衛隊は仲が悪く、占領した土地の統治をめぐって度々喧嘩をしています。
マイクロサービスにおいても、エンドユーザーにサービスを届けるという同じ目的であっても、 異なる部署は異なるＫＰＩを追いかけますので、所属部署や指揮系統が異なると対立する場合があります。そこで、どのサービスがどの部署に所属しているか？を素早く理解する感度の高さがとても重要です。
また、誰を握るべきか？どうすれば気持ちよく協力してもらえるか？を考えられるGood communicatorが欠かせません。基本的に仲良く楽しく仕事をしつつ、妥協できないところは絶対にしないというバランスの取れたコミュニケーションを意識する必要があります。感覚に頼らず良いコミュニケーションをしたい場合、ちょっと多すぎるくらいにミーティングを行い細かく話し合いことをオススメします。上司を利用した強権の発動も時には必要です。
トラブルの震源地はだいたい同じ
二つ目の問題はマイクロサービスだからこそ起きる、自分のアプリケーションは問題なくても他のアプリケーションが原因でトラブルに巻き込まれるケースです。
お互いのアプリケーションへの依存関係が強いマイクロサービスですが、トラブルの原因となるアプリケーション、つまり震源地はだいたい同じだったりします。
地震の発生頻度が二番目に多い日本ですが、過去の地震を見てみると震源地は九州地方の南部と東北地方の東部に固まっていることが分かります。震源地は特定の地域にまとまっています。
人間の身体こそ究極のマイクロサービスだと思いますが、人間にとって最も罹患率の高い病気は悪性新生物、つまりガンです。ガンに罹患するリスクがもっとも高いのは肺になります。
喫煙者が減少している近年でも肺ガンの死亡率が上がっていることは意外かもしれませんが、ホルモンと大気汚染が原因ではないか、、と言われています。無数の部分からなる身体においても、病気になりやすい機能は限定されています。
二つの例えと同様にマイクロサービスにおいてトラブルの発生源はおおよそ同じです。
依存関係が強い為に複雑な対応が必要になりそうな印象を受けますが、実は原因は一つ二つのアプリケーションで、それらのアプリケーションを修正すれば全体としても安定するケースが多いです。
とは言え、震源地の下には火山層があるように、ホルモンバランスは年齢と共に崩れやすいように、一つ二つのアプリケーションが不安定なのにはすぐに直せない何かしらの理由があったりします。そこでマイクロサービスにとって重要なのは、何かあった時に逃げられる避難先、つまりバックアップの存在です。
あまりにも不安定なアプリケーションがある場合は、BCPとして逃げられる他アプリケーションを確保しておく、もしくはアプリケーション自体を作り直してしまうといった判断が必要です。
モノリックと違うマイクロサービスの利点は、一部分のアプリケーションを付け替えるたり作り直したりできることですので、そのような判断が時には必要です。
まとめ
本日はマイクロサービスにおいて起こりやすい問題とその対策について説明しました。マイクロサービスにも利点と欠点があります。マイクロサービスを始められる方は上記をご参照いただけますと幸いです。
