3回目 マイクロサービスと作りたい物

スポンサーリンク

こんにちはKURANDで日本酒たっぷり飲んできてゴキゲンなるなです。
酔っぱらいの勢いで書いていきます。
今回は、マイクロサービスとはなにか?をこれから作りたい物に絡めて説明していきます。

マイクロサービスシステムとは?

マイクロサービスとは?wikiにはこうあります。

ソフトウェア開発の技法の1つであり、1つのアプリケーションを、ビジネス機能に沿った複数の小さいサービスの疎に結合された集合体として構成するサービス指向アーキテクチャ(service-oriented architecture; SOA)の1種である。


https://ja.wikipedia.org/wiki/%E3%83%9E%E3%82%A4%E3%82%AF%E3%83%AD%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9

つまり、ただの開発方法(アーキテクチャ)のことです。壮大な何かではないです。作る物自体、内容自体は何でもいいのです。

なんのための開発方法か?

マイクロサービスは、マイクロサービスでないシステムの欠点(後述します)を補うために考えられた開発手法です。

要は、大きいシステムを作らないで、ちっちゃいシステムをたくさん作って、連携させましょうっていうことです。

ちなみに、マイクロサービスでないシステムのことを「モノリシック・アーキテクチャ」または「モノリス」といいます。モノリス、モノリシックというのは、一枚岩という意味です。

以降、モノリスなシステムと呼びます。

モノリスなシステムの欠点

いかんせん素人なもんで、難しい話はあまりできません。
素人でもイメージしやすそうな簡単なところだけ説明していきます。
細かいことをいうと、他にも色々あります。
ご興味があれば、google先生に聞いてくださいませ…。

データベースの話

例えば、番組表をネットから拾ってくる機能があったとします。

この機能は、webから番組表をスクレイピング(webページから必要な情報を取ってくる)して、番組表テーブルを作るだけの機能です。
とてもすっきりしていますね。

ただ、これを元に録画をしていこうとしても、どの番組を録画すればいいかわかりません…。
なので、録画予約の機能を追加しよう。となります。

録画予約機能は、番組表取得機能が作った番組表を更新していきます。
実際録画したら、録画ができたことを分かるようにするために、番組表を更新していきます。

ところがここで、番組名が想定より長いものがあり、番組表のテーブルの定義では文字数が切れてしまう物があることに気がつきます
番組表の定義を変えないといけません

でも、今番組表を使っているのは3機能あります。
定義を変えても、3つとも正しく動いてくれるでしょうか?
もしかしたら、録画予約の機能で、画面に番組名を表示する時に桁数が溢れてエラーになるかもしれません

こんな感じで、色々な機能が1つのものを触るようになっていくと、定義を変えることさえ大変になってきます。

いやいや、そのくらいの変更、吸収出来るように作るでしょってツッコミは禁止です…笑

機能の話

機能の再利用も問題になることがあります。

やっぱり録画予約を毎回するのはめんどくさいなー。
webから番組の評価を拾ってきて、評価が高いものを勝手に録画するようにしよう!

となったとしたとします。
webから評価をとってくる→またwebからスクレイピングが必要です。

でも、前に似たようなものを作っていますね。
再利用しよう!という考えになることが多いと思います。

番組表取得機能からスクレイピングの機能を借りてきます。
うん、実装が減ってよかった(*´ω`*)と一時的にはなります。

ただ、こういう場合、番組表取得機能は、他から使われている意識がなかったりします。
webから無理やりスクレイピングしていたところ、
番組表取得用のwebAPIができた!
という情報を聞きつけ、スクレイピングをやめて、webAPIの利用に変更してしまうかもしれません。

そうすると、番組評価取得機能は動かなくなってしまいます

可用性の話

可用性(かようせい、英:Availability; アベイラビリティ)は、システムが継続して稼働できる能力のこと。

https://ja.wikipedia.org/wiki/%E5%8F%AF%E7%94%A8%E6%80%A7

番組表を取得する元のwebサイトが急に仕様を変更したとかで、莫大な情報をスクレイピングしてしまい、メモリーオーバーでサーバーが落ちたとします。

このシステムは一つのサーバー上で全てが動いているので、番組表取得機能が落ちると、全ての機能が落ちます。

そうすると、ただ番組表が取得できなかっただけで、録画中だったものが消えてしまいます…。

運用の話

モノリスなシステムは、全部の機能が一つのサーバー上にあります。
ロードバランサー使ってクラスタ構成(←よくわかってないけど、難しい言葉使いたかったw)にしても、結局は、全部同じものの上にのっています。

全部一つのサーバーにあるので、録画機能が動いている間は他の機能の修正や再起動もできなくなります。
番組表取得機能の微小なバグの修正をしたくても、録画が止められないので、デプロイができません。
録画予約するのがお客さんだとしたら、お客さんが録画予約機能を使う間も同じく、下手に操作ができなくなりますね。
そうすると、大した修正でなくても、夜間のリリースが必要になったりします。

まとめ

上記のような問題が起きるのは、いろんな機能がひとつのサーバーにひとつの大きなシステムとして存在していることが原因です。
モノリス(一枚岩)だからですね。

DBの定義が変わっても大丈夫なように実装しようとか、他の機能のものは使わないようにしようとか、ちゃんとルールを決めれば、一時的にはうまくいくかもしれませんが、システムは長期運用されていきます。
その間に、担当者も何度も変わります。
皆が皆そのルールを守るかも分からないし、分からないから、何か変更や追加をする時に、↑のような問題が起きていないか気に病む必要があります。
その結果、影響調査や、莫大な量のリグレッションテスト(↑のような問題が起きていないかのテスト)が発生します。大変…。
リグレッションテストとかもう、ほんとしたくない…。

マイクロサービスにすると?

それぞれの機能を独立させたシステムにして、サーバー自体を分けてしまいます。
青い四角がひとつのサーバーです。

各サービス(機能)は、物理的に他サービスのDBを直接覗くことや機能を使うことができないようになります。
別サーバーへのアクセスになりますからね。
やりとりはMQと言われる非同期のメッセージサービス(青線。説明すると長くなるので別回で説明します)とAPI(赤線)のみで行います。

こうすることで、↑で説明したモノリスなシステムの問題が解消されていくという訳です。

ただし、銀の弾丸ではないので、弱点やデメリットも当然あります。 ←すごい言ってみたかった!銀の弾丸!
開発がめんどくさかったりもしますし、そもそも、サーバーをたくさん立てる必要があるので、コストがかかったりもします。トランザクションの処理が大変だったりもします。←ちょうど今悩んでいる…

また、別の回で説明しようと思います。

作りたい物

ちょっと長くなってしまったので、さらっといきます。
もうメイン機能は↑で説明したようなものですが…。
作りたい物全体のざっくりな構想はこんな感じになります。

この各機能をそれぞれ独立したサービスにして、1ラズパイ使いたい。
むむむ、お金がかかる…。
既に3ラズパイじゃ足りなくなりました…。考えが甘かった…。

また、これもちょっと長くなりそうなので、詳細は次回持ち越しですが、DBの分散と、アプリの分散をするのも今回の課題なので…。
上の図をもう少し細かく書くと、こんな感じになります。

むぅ。こんなんでいいのか…。
分かりませんが、とりあえずこれで作っていってみようと思います。
なんかですね、私ラズパイって1コアだと思っていて、だからこれを思ったのですが、4コアもあるんですね、ラズパイ…。あんなにちっちゃいのに…。
なんか、無駄遣い感が半端ないです。
お勉強用だから、いいのかな…。

次回は、実際にラズパイを使ってみる編です!
ラズパイ、ほんとに初見のど素人ですが、一週間かけてとりあえず動かせるように頑張りますーー。

↓次回。頑張ったけど…??

スポンサーリンク
スポンサーリンク
近況報告
るなをフォローする
マイクロサービスの自由研究

コメント

タイトルとURLをコピーしました