マイクロサービスアーキテクチャ(Micro Service Architecture)で2025年の崖に対処せよ

2018年「Netflixのシステムは、2枚のピザに秘密があった。マイクロサービスアーキテクチャ(Micro Service Architecture)」
という少々長いタイトルでマイクロサービスアーキテクチャ(Micro Service Architecture)についてご紹介しました。

おかげさまで多くの人に読んでいただけて感謝いたします。

久々に「マイクロサービスアーキテクチャ(Micro Service Architecture)」ネタです。

今回のIT小僧の時事放談は、
マイクロサービスアーキテクチャ(Micro Service Architecture)で2025年の崖に対処せよ。 
と題して、2019年9月にヤフージャパン傘下に入った「ZOZOTOWN」を運営するZOZOの基幹システム刷新のお話です。

最後まで読んでいただけたら幸いです。

スポンサーリンク

マイクロサービスアーキテクチャ(Micro Service Architecture)

簡単におさらいします。

マイクロサービスアーキテクチャ(Micro Service Architecture)

ソフトウェア開発の技法の1つであり、1つのアプリケーションを、ビジネス機能に沿った複数の小さいサービスの疎に結合された集合体として構成するサービス指向アーキテクチャ（service-oriented architecture; SOA）の1種である。
マイクロサービスアーキテクチャでは、各サービスはきめ細かい粒度（英語版）を持ち、軽量なプロトコルを用いて通信を行う。
アプリケーションを異なる小さなサービスに分割することの利点は、モジュラリティ（英語版）が高くなることである。これによって、アプリケーションの理解、開発、テストがより簡単に行えるようになり、アーキテクチャの腐敗に対する弾力性が向上する。
マイクロサービスによる開発を行うことで、開発が並列化され、少人数の自律的なチームにより、各チームが所有するサービスを独立に、開発、デプロイ、スケールさせることが可能になる。
また、継続的リファクタリングを通して、個々のサービスのアーキテクチャ全体を置き換えることも可能になる。
マイクロサービスベースのアーキテクチャでは、継続的デリバリー（英語版）と継続的デプロイが可能になる。

ウィキペディアより

ちょっと専門的すぎるので　もう少し簡単に説明すると

1. 機能を分割して、それぞれを少人数で開発、それぞれの機能を一定のルールで連結して全体を構成
2. 機能は互いにAPIで呼び出すことになるためにある程度の独立性を持っている。
3. 機能追加、変更、システムのバージョンアップに対して最小単位での追加、修正で可能
4. 全体に及ぼす影響が出にくくなるためにシステムのメンテナンス時に最小限の停止もしくは、停止せずに稼働し続けることが可能

というように利点が多く、特に規模が大きなシステムでは、主流となってゆく開発技法となります。

次に、現在のZOZOのシステムについて説明します。

2000年前後のモノリシックなシステム

ZOZOTOWNの現行のシステム構成は、2004年あたりに構築されたもので以下の３つで構築されている。

1. IIS(Microsoft社 Internet Information Services)
2. SQLServer(Microsoft社 データベース）
3. ASP(Active Server Pages)
4. VBScript（言語）

2000年当時は、この４つの組み合わせでSQLServerにTransact-SQLで記述した「ストアドプロシジャ」中心で構築されているものが多い。

事実、IT小僧もこの組み合わせで多くのシステムを構築していました。

大きな理由は、圧倒的にコストがかからないことです。

2000年当時は、データベースと言えばOracleを使うことが多く、それにはかなりな出費が必要でした。

オンライン取引が、始まった当時としては、そのサービス自体が成功するかどうかわからないことも多く試験的な意味合いがあったため、多くのコストをかけることもできない。

そこで流行ったのが、上記の４つの組み合わせです。

データベースでオープン系を使うという冒険！は、ありえない時代で企業からも市販のもの以外許可も出ない時代背景もあったのです。
まだ、クラウドもなく、社内にサーバーを置くところがほとんどでした。

ですから、このシステムで組まれていることは、ある意味　正解です。

オンライン取引が、成功するかどうかなんて誰も予測できない時代に資金投入ができない事情もあったと思います。

通常ならば、取引の増大に合わせて、システムをブラッシュアップすべきなのですが、事業拡大優先となり、システムが置いていかれるという「典型的なパターン」だと思います。

必要なときに必要なリソースを調達

以前ブログで書いたのですが、Netflixのシステムは、この分野ではかなり先行していると思います。
想定される事象を先に試験をすることで対応する。
詳しくは、リンク先のブログで読んでいただければと思います。

「Netflixのシステムは、2枚のピザに秘密があった。マイクロサービスアーキテクチャ(Micro Service Architecture)」

クラウド、マイクロサービス、サーバーレスを利用する方法が、現時点では有効でしょう。

クラウドもマイクロサービスの概念を取り入れて設計することで
「使っていないリソースはすぐに落としてゼロ円」ということも実現できる。

必要なときに必要なリソースを調達できるという仕組みである。

よくAWSなどクラウドが時間単位の請求になっているので敬遠する企業やエンジニアの人を見かけるのですが、
それは、クラウドの「使い方を知らないエンジニア」になります。
また、「システムにかけるコストが、固定ではない」ことを嫌がる「時代遅れの経営者」に問題があるでしょう。

ある月のシステムの費用が膨らむ　＝　商売が拡大している
ということを理解できていないわけです。

止められないシステム

ネットサービスは、止めたら　その損失は計り知れないものであります。
ですから、多くのサービスは、ノンストップで動作しているのです。

その止めないための仕組として、以前は、サーバーを複数台用意して切り替えたりするなどしてきました。

しかし、クラウドとマイクロサービスで構築されたシステムで可能となるでしょう。

[amazonjs asin="B07FGDQPZV" locale="JP" title="クラウドネイティブ、マイクロサービス対応　最新システム構築実践ガイド"]

古いシステムの切り替え

一番大きな問題は、現行の古いシステムをどうやって切り替えるかにあります。
並行して新システムを構築し、一気に切り替える　ということも考えられますが、切替時のリスクも大きい

みずほ銀行のように大規模のシステムになると移行だけで１年がかりになる場合もあります。

今回のZOZOのシステムは、SQLServerのストアドプロシジャが大量にある場合、ストアドプロシジャからマイクロサービスに置き換える方法がありあます。
この手法を「ストラングラーファサード」とよんでいる。

Strangler Application Pattern　@ITより

少しずつ新しいサービスに切り替えて既存のシステムを刷新してゆくという方法が、コストや問題発生リスクを減らすにも現実的であると思います。

しかし、これを実現するには、旧システムのエンジニアとマイクロサービスに手慣れたエンジニアが必要です。

その解決方法の１つにマイクロサービスを活用するという手段もありますが、企業によってシステムは、環境や仕様が違っているため、どの方法がベストということは難しい。

まとめ

IT小僧は，今回のZOZOTOWNのようなシステムを４０以上も納品してきました。
さすがに20年近い年月なのでとっくに刷新されていると思います。

システムの構築はおカネがかかるので、経営者は、システム費用と聞いただけで嫌な顔をします。
（する人が多い）

「システムは、利益を貪る怪物のようだ」
なんて言う経営者もいるぐらいですから、社内SEで苦労されている方も多いと思います。

そんな状況で十数年前のシステムを使い続けている会社　結構多いのではないでしょうか？

古いシステムを機能追加することでシステムが膨れ上がり、最後には自滅してしまう。
恐竜が絶滅したように　ある日　突然死するのが、システムです。

今日、動作しているけど、来週、使い物にならなくなる可能性だってあるのです。

突然死や不具合が連発する前に手を打つべきだと思います。
ただ、予算をつけてくれないんですよね。

システムが停止したら業務が止まるというのに・・・

スポンサーリンク