LoginSignup
0

More than 5 years have passed since last update.

MSAについて色々

Last updated at Posted at 2016-11-30

この記事はAltPlus Advent Calendar 2016の1日目の記事です。軽いジャブくらいの気持ちで読んでください。初日の挨拶はこちらです。

はじめに

そもそもこの記事を書こうと思ったきっかけは次の通りです。友人が「MSAってよく言うしなんとなくわかるけど、じゃあ作れと言われた時よくわからないよな」のようなことを言っていて、実にその通りだと感じとりあえずやってみようと思いたったのが初めです。

そのためこの記事はマイクロサービスアーキテクチャについてものすごく深掘りするわけではなく、わかりきってることをちょっと確かめてみようという程度のものです。感想文です。過度な期待は禁物ですよ。

そもそもMSAって

マイクロサービスアーキテクチャ、いいですね。もう語感からしてかっこいいです。

教えてGoogle先生! を行うと情報が山のようです。いいですね、このミーハーな感じ。バズワードってやつです。

きっかけとなったらしいファウラーさんのブログには以下のようにあります。

The term "Microservice Architecture" has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services.
この「マイクロサービスアーキテクチャ」という用語は、ソフトウェアアプリケーションを個別に展開可能なサービスのスイートとして設計する特定の方法を説明するために、ここ数年に誕生しました。

つまり、一つのアプリケーションを細かく分解し、それぞれ別のアプリケーションとして展開し、それが一つのサービスとなる設計のこと、でしょう(適当な要約)。

考えてみる

取りあえず簡単に作ってみよう。

作りたいもの

艦これの情報をdiscord(チャット)に流したい。

構成

  • サービス1: 艦これについての記事をクローリングする(今回は公式Twitterのみから情報を取得)
  • サービス2: それをdiscordに流す
  • サービス1とサービス2はAPIで連携する

スクリーンショット 2016-11-30 16.26.31.png
こんな感じ?

作ってみると

作ってみた過程、詳細などはカット。特別なことは何もしていませんし、これらの情報はwebに溢れています。だいたい上記の通りです(今度別記事としてあげることにしました)。

さて、マイクロサービスマイクロサービスと連呼され続けていますが、作ってみた感想を並べ立てていこうと思います。

正直面倒臭い?

今回簡単に、至極簡単に作ってみましたが、それでも結構めんどい。

サービスを細かくして増やせば増やすほど、準備することや考えることが増えていきます。それぞれにDBが必要でしょうしAPIは都度必要に応じて作らなければなりません。

ですが、これは一人で開発した時の話で、複数人で開発するときは逆にやりやすいのではないかなと思います。環境や作業状況を他人に左右されにくいというのは非常に大きい。各々好きな技術を使うこともできます。ただ、あまりに好き勝手やっていった結果、最新の技術ばかり使われ、後々メンテできる人がいなくなった、なんてことにはならないよう気をつけなければなりませんね。

運用しやすそう

適当に作っても、機能追加や障害対応などもやりやすそうなイメージがあります(サービス同士の依存性が高くなければ)。どうしようもならなくなった時、特定のサービスのみをリプレースするというのもやりやすそう。

というのはおそらく今回が非常に小規模なものであるからでしょう。サービスが大きくなり、比例してサービスの数が増えて行った時、障害の特定や解決などは大変だという話をよく聞きます。

機能追加する場合も、既存のサービスに追加するか、新しくサービスを追加するかはちゃんと考える必要があるでしょう。あれこれ適当にして行ったのでは収集つかなくなりそう。

委託しやすそう

このサービスだけを頼みたいな〜、なんて考えた時やりやすそうだなと思いました。多くのサービスの中の、一部の簡単なサービスの運用保守ならどこかに任せてもいい気がします。

トランザクションが大変そう

今回はトランザクションが問題にならない構成でしたが、依存性が高くサービス間のトランザクションが必要になってくることもあるかと思います。これは始める前から思っていたのですが、調べてみるとそんな話がいっぱい出てきます。解決法としては、依存性が高くなってしまうものはなるべく一つのサービスとしてまとめる、ローカルでトランザクションを貼る->ローカルの更新処理を全て行う->更新系のAPI->成功したらコミット、などがあるようです。私の経験的には、似たようなものを作る時、何かの更新のたびAPIを叩いて通知した記憶があります。

こういうことも考慮に含めてシステムを構成する必要があるのでしょう。

終わりに

ミーハーな感じに済ませてしまいましたが、読み返してみれば当たり前のことしか言ってませんね。

マイクロサービスマイクロサービスと言われ続けて、なんかすげえ! という気分になってきますがコンパクトに作ってしまえば、非常に理解がしやすいです。それほど特別なことではありません。

ある程度大きなものを他者と共同で作ろうとした時、多かれ少なかれ似たようなことはこれまでもあったと思います。SIer的には認証基盤を別に設けたり、溜め込んだデータを解析したり・・・、なんてことを下請けに発注して、みたいな闇の話。それはともかく、今までもあったシステムの作り方を、さらに細かくして、名前をつけたのが、つまるところマイクロサービスアーキテクチャと呼ばれるものだと思います。

まあ実際にやろうとした時、構成はどんどん複雑になってくるのでしょうけれども。。。

ということでAltPlus Advent Calendar 2016 1日目の記事でした。

2日目はcimadaiさんです。よろしくお願いします!

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0