Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to 今更ながらの「マイクロサービス」
Similar to 今更ながらの「マイクロサービス」 (20)
More from Hideaki Tokida
More from Hideaki Tokida (20)
今更ながらの「マイクロサービス」
- 1. 今更ながらの 「マイクロサービス」 Innovation Hub 九州 Developer Day Hideaki Tokida ⽇本情報通信株式会社 ArchitectureとBluemixでの実装⽅法のヒント
- 2. 0 ) 0 r e 4 0 0 0 • k dinp ah • m U A IH M TA @lc sxu • O U o • @ . ( O • 40 lc ! • tCG BW • 0 4 4 ¥30 6 4 1/0 2: - 89 73
- 4. マイクロサービスの本格化 • 海外の代表的なIT企業（Netflix,Amazon, Uber,Twitterなど）がここ数年 で従来型のアーキテクチャからマイクロサービスアーキテクチャを採⽤。 それはこれまでとアプリケーションに対する要求が変わってきたから • マイクロサービスは従来のモノリスなアーキテクチャに対してスケーラビ リティ、効率、新しい技術の適応と⾔った所で効果的があるとされていま す。
- 5. 2004-2017 までの検索⼈気の⽐較 （マイクロサービス vs サービス指向アーキテクチャ） 2017年の”マイクロサービス”の分布 2017年の”サービス指向アーキテクチャ”の分布
- 6. Service-Oriented Architecture • SOAは、複数のサービスが連携して⼀つの機能を提供するための設計⼿法。 • 問題が⾊々あった→どの位⼩さくサービスを分けるべきかという⽅法論、 通信プロトコルやSOA「製品」に帰属する問題。 • マイクロサービスは、SOAの⼿法の⼀つ。
- 13. 似て⾮なるもの • 共有ライブラリ • ⾔語標準的な分解テクニック。ライブラリは⾔語にいぞするため技術異 質性（多様性）が失われる。ライブラリ単独ではスケールできない。DLL 以外の場合には新しいライブラリのために全体を起動する必要がある。 • モジュール • ⾔語ごとにモジュールを利⽤する⼿段は違う。モジュールが過度に結合 する事があり得る。共有ライブラリと同じ問題点を持つ。
- 16. 推奨されるスタート • Monolithでアプリケーションを作成 • 初期の段階で適切にどのように分割するかわかることは難しい • ドメインを正確に理解した後にマイクロサービスに分割 • より柔軟なリソースの変化に耐えるためにクラウドサービスの利⽤を推 奨 • 特に結合しがちなDBなどは注意が必要
- 19. マイクロサービス間のやり取り 機能A サービス 機能B サービス XML-RPC SOAP Protocol Buffer REST API (Application Programing Interface) 伝統的に利⽤されていたRPCよりもより技術⾮依存であるRESTが⽀持されている。 （特定の分野ではProtocol Bufferなどを利⽤するほうが良いこともあるため何でも かんでもRESTというわけではない）
- 20. REST • RESTは、通信プロトコルは定義されていないがHTTP上で利⽤されるのが ⼀般的である。 • 特にHTTP動詞（GET, POST , PUT等）と、URLをリソースとして扱うこ とで⾮常に相性がよく利⽤することが出来る。例えばSOAPもHTTPで利 ⽤されているが動詞部分はXML内で定義され通常はGETのみ • REST上で流れるデータ構造はJSONそしてXMLが利⽤されます。JSONは より容易に書くことが出来る反⾯XMLの持つリンクや厳格なデータ構造を 持つことが困難です。
- 21. コンウェイの法則 • 「あらゆる組織は、必ずその組織のコミュニケーション構造に倣った構造を持 つ設計を⽣み出す」 Melvin Conway • 組織はアーキテクチャに、アーキテクチャは組織に倣う • マイクロサービスアーキテクチャを採⽤する場合には、組織もそのドメインに そうことが望ましい（有名なのは、Amazon Web Servicesにて採⽤さている two-pizza / 2枚のピザで⾜りないほどの⼤きなチームにすべきではない） • マイクロサービスアーキテクチャを駆動させるプラットフォーム(インフラ 層〜アプリ層までの間）を管理するチームは必要→クラウド利⽤の利点
- 22. Bluemix上でマイクロサービスを作るためには • 最終的な各サービスは何かしらの機能を持ちそれはHTTP(S）通信を利⽤して RESTを利⽤しJSON(またはXML)でやり取りするサービスを作る必要がありま す。 • そしてそれらの各サービスはより容易に試験を⾏い本番環境、開発環境などに デプロイされる必要があります。 • クラウドサービスを利⽤することでマイクロサービスを実装するのに必要なプ ラットフォームを⼿に⼊れることが可能です。そしてマイクロサービスを実⾏ する時のハードルとなるマイクロサービスのプラットフォーム⾃体の運⽤とい う部分を⾏わなくても良いことが最⼤のメリットです。
- 23. 主なクラウドで利⽤する機能 • 継続的インテグレーション・継続的デリバリ • 様々な形式でのアプリケーションの実装の選択肢 • API利⽤における⽀援 • 総合的なログ運⽤の実装
- 24. 継続的デリバリ • Continuous Delivery を⾏うための Build Pipelineを作ることが出来るツー ル郡が⽤意されている。 • Build Pipelineではコードがコミットされたことを検出し、コードをチェッ クアウトしビルド・テストそしてデプロイすることが出来る。 • 標準のBuild Pipelineでは、Cloud Foundry Application , Kubernets ContaienrをBluemix環境にDeployするための設定がプリセットされている ためすぐにでも継続的デリバリを始めることが出来る
- 25. Source Code Repository (git.ng.bluemix.net ) Build Pipeline (ServiceA) serviceA Build -002 Service B Build-002 Service C Build-002 Build Pipeline (ServiceB) Build Pipeline (ServiceC) Repositoryの変更を監視 Pipelineサービス上で定義された Buildライン 成果物をサービスとしてデプロイ Build TEST Deploy 複数の定義を組み込むことが可能 （Shellが利⽤出来るので必要があれば柔軟に対応することが出来る） 成果物 成果物 Bluemix Platform （CF or Kubernnets) Deploy UNIT テスト 性能 テスト ひつように応じて複数のテストを実施
- 26. Bluemixという実装 • BluemixのようなPaaSやContainer環境に対してサービスをDepoyする場合に は、利⽤者はより抽象化された中で作業を⾏う。 • 具体的にはどの物理（仮想）サーバでBuild成果物が動作しているかは⾃動的に プロビジョニングされるため意図的な操作は不要です。またBluemixの場合には 成果物以外にもデータベースなどのサービスも簡単に利⽤する事が出来るように 構成されています。 • Buildフェーズでは、CFの場合にはソースをチェックアウトし適切なBuildpack を元にBuild処理が実⾏され成果物(droplet）が製造される。これはVM等の場合、 ⾃⾝でChef,Ansibleなどを⽤意することから⽐べれば多くの作業を軽減出来る。
- 27. 成果物 成果物 Bluemix Platform （CF or Kubernnets) Deploy コンテナ コンテナ コンテナ Buildpack App OS App OS App ホスト カーネル VM 成果物はそれぞれの⽅式 で適切に配置される Bluemixにおける購⼊単位
- 28. 適切なアーキテクチャの選択 責任範囲 ステー トレス 従来か らの互 換性 Blue mix サー ビス 連携 開発速 度 Standar d Portabili ty Securit y Performan ce Reliabilit y HW OS Bin Lib Code IaaS ✓ ✓ ✓ ✓ ◎ X X ◎ ☓ ◎ ◎ ◎ Docker ✓ ✓ ○ ◎ ○ ◎ ◎ △ ◎ ○ Cloud Foundry ✓ △ ◎ ◎ △ △ (IBM) ○ ○ Cloud Functions ✓ ○ ☓ ☓ ◎ ☓ ☓ (IBM) ○ ○
- 29. より⼩さい機能の提供 • Function as a Serviceとしての IBM Cloud Functions (旧OpenWhisk) • 主な2つの機能 • イベント駆動型 • あるサービスの変化（イベント）に応じて処理が実⾏される（状態変 化を監視するプログラム無しで実⾏される）現⾏では CloudantNoSQL、MessagingHubなどと連携可能 • 関数型 • シンプルなリクエスト／レスポンス型の処理が実⾏される。特に Function as a Serviceの場合には処理（具体的には、⾔語のFunction 部分）のみを記述することで動作する • クラウドらしい料⾦体系 • 実⾏した回数、実⾏時間、実⾏時のメモリで課⾦がされる。 https://github.com/IBM/openwhisk-serverless-apis
- 30. マイクロサービス間の連携 変更する サービス PHP Nodejs Java Java PHP Java Golang API • 各サービス間の連携はおもにRESTで接続される • 各サービス感は必要最低限の情報のみをやり取りする • あるアプリケーションから見て、他のサービスはアタッチ可能な リーソースのように振るまう
- 31. マイクロサービス間の連携 PHP API •Cloud Foundry, Cloud Functions のアプリケーションは、標 準でAPI保護機能を持っている。（ワンクリックでAPIのみを公 開する⽤に定義することが出来る） •API Managementの機能はシンプルだがSwaggerをサポート しておりスモールスタートとしては⼗分の機能を備えている Golang API API •Coustom API (Service) の機能を利⽤すると、アプリケーショ ンからアプリケーションへ接続するための情報を環境変数として 引き渡すことが出来る。（Bluemix上のサービスのように振る舞 う。ここでは実体はなくVCAP_SERVICESのやり取りのみ） •任意の値をJSONで引き渡すことが可能。
- 32. 認証 • Cloud Foundry , Cloud Functions では API Managementの機能を利⽤ するとAPIキー発⾏の機能やOAuth連携を有効にすることが出来る。 • より⾼度な認証・認可のためにAPI Connectを利⽤することも可能。個々 のアプリケーションの認証のためには Single Signon サービスが提供さ れている。 • (現⾏のBluemixでは発⾏されたAPIキーの操作ログを取得するサービスが 提供されていないので監査⽬的の場合にはリクエストを受ける側などで実 装が必要 or IBM Cloud Active Tracker）
- 33. 統合されたログ蓄積 • Bluemixでは、Log Analyticsサービスを利⽤することでログを収集することが出来る。(サー ビスを利⽤することで保管する容量や⼀⽇あたりの検索可能な容量を変更することが可能） • ログ検索では標準的になってきたElasticSearch＋Kibana5を利⽤ Log Analytics サービス Cloud Foundry Kubernetes VM/Bere Loggre gator STDOUT,STDERR STDOUT,STDERRLogコレ クター Logstas h LOG Kibana
- 35. IBMの公開している情報 Microservices with IBM Cloud Functions and Cloud Foundry Microservices with Kubernetes
- 36. まとめ • マイクロサービスは、様々な変化に対応する事が⽬的です。リソースの拡⼤ や新しいリリースを⾃由にする出来る事が必要です。そのために機能毎に⾃ 律性・技術特異性などを持たせる必要があります。 • 現在のシステムを将来的にマイクロサービス化するかしないかにかかわらず ドメインでシステムを分離する（またはどこが密結合しているか）を調べる ことはシステムの安定した運⽤（障害時の影響範囲の推測など）にも有⽤ • 出来るところからマイクロサービス化／合わせてクラウドサービスの利⽤を 検討する
- 37. 参考⽂献 書籍 1. マイクロサービスアーキテクチャ OʼReilly Japan / Sam Newman 2. プロダクションレディ マイクロサービス OʼReilly Japan / Susan J.Fowler 3. エリック・エヴァンスのドメイン駆動設計 (IT ArchitectsʼArchive ソフトウェア開発の実践) Web上の情報 • Microservices https://www.ibm.com/devops/method/content/architecture/ microservices/2_0 • The Twellve Factor Apps（⽇本語）https://12factor.net/ja/