BT

QCon New York 2017: マイクロサービスアーキテクチャを進化させる

| 作者: Andrew Morgan フォローする 3 人のフォロワー , 翻訳者 sasai フォローする 0 人のフォロワー 投稿日 2017年7月30日. 推定読書時間: 4 分 |

原文(投稿日:2017/07/15)へのリンク

QCon New York 2017にて、Andrew Hart氏はマイクロサービスアーキテクチャの進化について、SeatGeekにおける実例を多数挙げながら、そのアーキテクチャ、組織、運用といった面について語った。

あらゆるソフトウェアシステムは実際に何らかの形で相互接続されている、とHart氏は主張する。望むか望まないかにかかわらず、すでにあなたはマイクロサービスアーキテクチャを持っています。テクノロジ、スケール、組織などの様々な要因から、ソフトウェアは常に変化するものだ、と彼は考えている。マイクロサービスは進化的アーキテクチャによって、その変化を助けてくれる。重要なことを以下にあげる。

  • マイクロサービスをモデリングするときは、それぞれの機能をアトミックなものとして扱う。
  • マイクロサービスは必ずしも投げ込まれたものを吸収してくれないため、キャパシティプランニングに責任を持つ。
  • マイクロサービスのDevOpsは複雑であり、そのアーキテクチャパターンはPaaSからかなり恩恵を受ける。
  • ユビキタスなモニタリングは重要であり、運用リスクを特定するためのキーになる。
  • 技術的関心ではなく、機能中心にチームをモデル化する。

Hart氏は、それぞれが単一機能に対応するという意味で、マイクロサービスはアトミックであるべきだと考えている。ご存知のように、これをうまくやるのは難しいが、こうした機能について考えることで、メンテナンス可能なマイクロサービスアーキテクチャが実現できるという。

彼は現実世界のユースケースとして、SeatGeekにおけるチケット正規化の問題について説明した。これはマーケット横断のチケットコード統一ビューの提供に伴うものだ。複数のマイクロサービスがこのロジックにアクセスする必要があったが、時間的制約のために、コードは重複していた。このコードが複数の場所にあることは、システムのメンテナンス性に影響を与えていた。コードの変更を繰り返すことになり、間違いの余地が増えるためだ。彼らは正規化を機能として考えることで(そうしておくべきだったのだが)、それ自体をマイクロサービスとして抽出し、明確に定義されたインターフェイスを与え、技術的負債を取り除いた。

彼はマイクロサービスのもう一つの誤解、新しいコンポーネントをシステムに追加もしくは統合することは単純あるいは容易であるという誤解、について指摘した。実際には、キャパシティプランニングが重要になる。マイクロサービスは必ずしも投げ込まれたものを吸収してくれないためだ。

彼はSeatGeekにおける事例として、新たに買収した主要チケットシステムの統合について説明した。これは難題だった。よく知らない言語で書かれており、使いにくい不恰好なSOAP APIを提供していたためだ。なんとかしようと、チームは新しいSG Public APIを構築した。これは基本的に、新しいSOAPシステムと既存のサービス間のプロキシとして振る舞うものだ。データを変換し、シンプルなインターフェイスを提供する。元のAPIの複雑さを抽象化することで、APIをサードパーティにも公開できるようになった。最終的に重要になったのは、このためのキャパシティプランニングだったという。

また彼は、マイクロサービスアーキテクチャにDevOpsを持ち込むよう主張した。システムが分散していると、従来のモノリシックなシステムにはなかった運用上の懸念が増える。このため、マイクロサービスはPaaSでうま機能する。インフラをシンプルにして、アーキテクチャを進化させるという。

彼はまた、最も重要な運用上の懸念の一つはモニタリングであると指摘した。SeatGeekにおける事例として、グラフのスパイクによって、イベント前にあまりに多数のPDFチケットがダウンロードされたことがわかった例をあげた。こうしたメトリクスのおかげで、会社はモバイルアプリのバグを特定することができた。さもないと、このバグは発見されなかったかもしれない。

Hart氏は組織に関して、チームの分割方法がデリバリに影響を与えるおそれがあると考えている。新しい要件がやってきて、アーキテクチャを進化させるにつれ、チームを再構築する必要があるだろう。チームは技術的関心ではなく機能中心にモデル化する。機能がチームをまたいでしまうと、デリバリは非常に難しくなる。これらの原則はConwayの法則で証明されている、と彼は説明する。

結論として、マイクロサービスを進化させるのは難題だが、アーキテクチャ、組織、運用上の懸念について考えることでもっと簡単になる、とHart氏は考えている。最終的に、マイクロサービスの恩恵ははるかに大きく、そのおかげでSeatGeekは短期間で提供できたという。

Rate this Article

Adoption Stage
Style

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

特集コンテンツ一覧

.NETの派生を理解する

Wayne Citrin 2018年7月18日 午前3時44分

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT