気の向くままに書き綴る

勉強会参加したメモや日々の思ったことのメモ等

docker-compose.yml からwercker経由で Amazon ECS 上にコンテナを展開する

先日、AWS New Service Meet upに参加してきた。※まとめ資料

AWS ECSのサービスを聴きながら、手元で利用しているdocker-composeをそのまま本番に反映できたら、

手元の環境から本番環境まで差異がほぼなくなってすごく良いんじゃないかなと思って以下のツイートをした。

 

 

werckerを使ってやってみた。

(こっそりその日にdocker-compose.ymlを AWS ECS 用のjson形式に変換してくれるcontainer-transformを教えてもらい、試した系の記事です)

※ container-transformはAWSサポート対象外

 

pip install で以下のモジュールをインストール

awscliの設定について

 

事前準備

インスタンス、IAMのロール、Advanced Detailsの設定などキャプチャがあってわかりやすいのでこちらをご参照

 

docker-compose.ymlを用意。

$ cat docker-compose.yml

base:
  image: ubuntu 
  cpu_shares: 512
  mem_limit: 536870912b
  command: echo "hello world!"
  • 試しにjson形式に変換してみる
$ cat docker-compose.yml | container-transform 
[
    {
        "memory": 512,
        "cpu": 512,
        "image": "ubuntu",
        "command": [
            "echo",
            ""hello",
            "world!""
        ],
        "essential": true,
        "name": "base"
    }
]

このように、json形式に変換してくれる。

  • 上のjson形式をtask-definitionに登録。
  • AWS ECS は、実行するDockerコンテナをタスクというグループ単位で管理している。
  • register-task-definitionはそのタスクを登録する。
  • つまり、docker-compose.ymlに書かいた内容を登録する。
$ aws ecs register-task-definition --family your_task_definition --container-definitions "$(cat docker-compose.yml | container-transform)"
  • register-task-definition で登録したタスクを実行するにはrun-taskを使う。
  • --countを使うとdocker-composeのscaleみたいなことが出来る。
  • インスタンスのリソースが足りない場合は、起動できないって返ってくる。
$ aws ecs run-task --cluster your_cluster_name --task-definition your_task_definition_name

werckerからECSのコンテナを起動

f:id:koudaiii:20150428204958p:plain

上のコマンドを覚えて叩くのが大変なので、wercker のboxとstepを作った。

git push やGithub上でリポジトリを更新した際にAWS ECS上にコンテナを展開させることが出来る。

 

  • 処理の流れ

f:id:koudaiii:20150428213613p:plain

 

以下は簡単なSample。

Deploy設定例(wercker step)

上記の事前準備行った上で、

  • wercker.ymlを用意
  • werckerのdeploy piplineに値($AWS~~~と書かれている部分)を設定

 

sampleで作成したもの

例:wercker.yml

box: wercker/python
build:
  steps:
    - script:
        name: Hello World
        code: echo "Hello World"
deploy:
  steps:
    - koudaiii/install-container-transform:
        key: $AWS_KEY
        secret: $AWS_SECRET
        region: $AWS_REGION
        cluster: $AWS_ECS_CLUSTER
        definition: $AWS_ECS_DEFINITION
        count: $AWS_ECS_COUNT
  • werckerのDeploy piplineの設定箇所

f:id:koudaiii:20150428215353p:plain

 

 

CI用の設定例(wercker box)

同じようにの事前準備をした上で、

  • wercker.ymlを用意
  • werckerのpipline(上のDeployの設定とは違う場所)で値($WERCKER~~~と書かれている部分)を設定

 

sampleで作成したもの


例:wercker.yml

box: koudaiii/install-container-transform
build:
  steps:
    - script:
        name: Configuring based on parameters..
        code: |
          aws configure set aws_access_key_id $WERCKER_INSTALL_CONTAINER_TRANSFORM_KEY
          aws configure set aws_secret_access_key $WERCKER_INSTALL_CONTAINER_TRANSFORM_SECRET
          aws configure set default.region $WERCKER_INSTALL_CONTAINER_TRANSFORM_REGION
    - script:
        name: register task definition
        code: |
          aws ecs register-task-definition --family wercker --container-definitions "$(cat docker-compose.yml | container-transform)"
    - script:
        name: create run task
        code: |
          aws ecs run-task --cluster $WERCKER_INSTALL_CONTAINER_TRANSFORM_CLUSTER --task-definition wercker
    - script:
        name: Done.
  • werckerのpiplineの設定箇所

f:id:koudaiii:20150428215429p:plain

 

ここまで、書いて一旦終了。

 

まとめ

CI側について

これをそのままcommandをrspecコマンドに書き変えると、jsonが返っくるだけで、これ、、必ずテストがgreenになる世の中になりそうやで。。。 

また、CIを一気に回しまくるとrun-taskの実行の際に、インスタンスのリソースが足りずコンテナの展開ができないなどの事象が発生する。

もう一工夫が必要。

 

Deploy側について

コンテナの展開だけじゃなく、最終的に以下の内容も含めてwercker-stepで実装したらblue-green deploymentに近いことが出来そう。

これでDockerのホスト側の面倒を減らすことが出来るのでは?と妄想している。

  • 新規にインスタンスの起動(リソース確保のため)
  • タスクUpdateで切替

出来上がりのイメージ図

※ 実際にawscliからイメージ図の作業が出来るかは不明です><

 
現時点の課題

docker-compose.ymlで書いた構成がECSでインスタンスを超えてスケーリングしていく未来にならないかなぁー。

最初に書いたこのツイートについて、 いろいろ触ってみて現時点では、以下の点からまだまだ解決すべきものがいっぱいありそう。

  • AWS ECSがdocker-composeをサポートしていない点
  • container-transformがAWSでサポートしていない点
  • docker-compose自体がそもそもproductionの利用を推奨(以下サイト抜粋)していない点

Docker Compose Overview Compose is a tool for defining and running complex applications with Docker. With Compose, you define a multi-container application in a single file, then spin your application up in a single command which does everything that needs to be done to get it running.

Compose is great for development environments, staging servers, and CI. We don't recommend that you use it in production yet.

 

今後何らかの方法で解決していけば、

docker-composeでアプリの構成を管理しつつ、

local - development - QA/Staging - production 間の環境差異がさらになくなる。

 

それ以外に、コンテナならではの以下のようなことも出来る。

  • CI系のサービスでテストが増えて遅くなってしまっている場合に、コンテナで並列処理
  • エンジニアじゃない方(local上に環境を作って確認するのが難しい方)でちょっと文言とかCSSを変更したい場合に、直接Github上で編集してcommitしたらコンテナが起動してWeb上で確認

 

今後、どのようなUpdateが入るか楽しみです!!

Why we chose microservices?

2014年7月2日にPostされたBlogを読んだ。タイトルはBlogの小項目の抜き取ったものなの。

 

Blogと一緒にこのBlogのランディングページを確認すると、KarmaというWiFiルーターをレンタル(?)しているスタートアップ企業だと思う。

 

Blogにもあるけど、「ユーザーがStoreからWiFiルーターを申し込んで、FedExからWiFiルーターが届くといったシンプルな仕組み」らしく、設立当初はフロントとバックエンドでチームを分けてアプリケーションを作っていたらしい。

 

しかし、ビジネスがスケールしていく中で、一枚岩のバックエンドでは、手に負えない状況になっていく。それに対してどうアプローチしていったかがわかる。

 

microservicesをやりたくて行ったものという話よりかは、「自分たちでアジリティを出すために、どう改善していったか。」そして気がついたらmicroservicesだった。という印象をうけた。

 


How we build microservices at Karma | Karma

 

どのように私たちはKarmaでmicroservicesを構築したか

microservices、microservices architectureは、developerでHotなバズワードだ。しかし、具体的な例はまだ不足している。
そこで、過去数年間にわたるKarmaでのBackend APIのmicroservicesの取り組みが役立つかもしれない。

それは正確な「How to」より「why to」「wherefore-to」というようなものである。

microservicesが自身のApplicationに適しているかどうか、いくつかHintになると思う。そして、どのように適用していくか考えるきっかけになると思う。

なぜmicroservicesを選んだか?

Karmaを始めた時、私たちは、主に2つの部分(Backend API、Frontend Application)にプロジェクトを分割することを決めていた。

Backendは、店舗からの注文処理、使用量アカウンティング、ユーザー管理、デバイス管理等に責任をもつ。同時にFrontendはBackend APIにアクセスするユーザーのためのダッシュボードを提供する。

このことから我々はもし全体のBackend APIがモノリシックであれば、すべてがもつれて、うまく機能しないことに気づいた。

 

例えば、私達はユーザ、デバイス、及び店舗を持っている。
想像できるように、ユーザーは店舗からデバイスを購入する。
それは簡単に聞こえる。

 

しかし、一個のApplicationだった時、User関連のコードがDevice APIで終わり、Store APIは、Device APIを裏側で実行し、実際のスタッフが動く。

それは、「何がどう動いて」、「何が触れ」、「何が変わった」か追跡することは困難だ。

 

私たちは、Library毎にモノリスを分離し、一つのAPIとして組み合わせていた。

 

しかし、そのアプローチには3つの主要な課題があった:

  • Scaling

スケールするときは、一度に全体のAPIを拡張しなければならない。

Karmaの場合には、UserとDeviceのAPIはStore APIよりもはるかに高速スケールする必要があった。

 

  • Versioning

Libraryアプローチでは、単一の依存がApplicationのBackend全体をHoldする。
例えば、Rails3からRails4へののアップグレードは難しいです。すべてのコードが複数のプロジェクトにまたがっているからだ。

現在私達は、一度にすべてを更新する必要はありません。実行中の古いAPIを残して、必要なタイミングでそれらをアップグレードすることができます。

 

  • Multiple languages and frameworks

今、私たちは主にRuby屋だ。しかし、私達は新しい技術と言語の実験することが出来るようにしたい。
現在は、GoやClojureを利用している。なぜなら、すべてのサービスは、REST APIを公開しているからだ。コミュニケーションに問題はない。(最終的にすべてHTTP通信だからだ)

 

microservicesの最大ブーストはProgrammerの生産性である。
頭の中で全体のことを維持する必要ない!すべての目移りを取り除く。

 

どう始めたか 

Backendの大きなApplicationを細かくピースに分離することから始まった。
この動きは、私達にとって学ぶことができ、とても大きかった。
Applicationを作っていく中で、私達は課題に対して精通し、Applicationの側面で必要な境界が明白になった。

 

そしてどのようにApplicationを分割すべきかクリアになり、サービスに当てていった。

 

最初は、比較的大きかった分割だったが、他のmicroservicesの採用と同じように、私たちはそれらを小さく、小さくすることができた。

 

例えば、大きなApplicationである「Store」から始まった。
その後、取り扱い及び出荷機能を分割。
その後、出荷が別々の分割出来ることを発見した。
その後、出荷トラッキングが最初の場所でそれを出荷するのと異なる役割であることがわかった。

店舗は、現在3つのAPIで構成されています。

私たちの次のステップは、より多くの処理順序を分割することであるかもしれません。
私達は常に最善の方法を学習している。

microservicesは私たちにその柔軟性を提供します。最終的に、microservicesは、単一責任していくことが一番良い。(サードパーティの依存関係のほとんどを包み、Applicationが他のApplicationについて考える必要がない状態である)

 

microserviceを1,2週間で構築/再構築し、他のApplicationの書き換えを必要としない。
依存関係の更新以外で二年前に書いた「Collector」はそれ以来触れていない。

What our architecture looks like now

microservicesにはHTTPとメッセージキューの2つのコミュニケーション手段がある。
私達はBackend側をHTTPでsinatraを用いるところから始まった。サービスは、相互にURL介してメッセージを渡す。これは、処理が必要なタイミングで行え、非常に良かった、
しかし、これは指数関数的に複雑になっていった。
たとえば、オーダーが来て、それが出荷される必要がある。

それは十分に簡単ですが、もし私たちは注文が受信された後に複数の処理を行いたい場合は?

 

ストアは、請求書の話をする必要がある。またはメトリクスやメーラーAPIを使いたい場合があります。

つまり、Store Application内のエコシステム全体で多くの知識をパックしている。
それは、​​動作するのが困難になる。だから我々は、Event-baseでタスクの一部を分割し始めた。

 

私たちは、Publishing EventsとしてAmazon SNS(Simple Notification Service) を利用する。そして、Amazon SQS (Simple Queue Service) でEventを格納する。


SNSは、サービスに渡されたメッセージを受け取り、SQS経由で適切なキューにそれをPublishしている。

 

Microservicesは
・キューからジョブを取得
・処理
・成功した場合、ジョブを削除
プロセスが失敗した場合は、メッセージをキューに戻り、別のインスタンスのProcessが取得しにいく。

f:id:koudaiii:20150207021527p:plain

当社のプラットフォーム·アーキテクチャの簡略図

 

新しいマイクロサービスをデプロイする時、設定ファイル(listen message,type説明)と公開したいメッセージのタイプが含めている。「Fare」と呼ばれる設定内容を読み取る社内のツールを持っていて、適切なSQSやSNS·キューを設定する。

 

注文が来た時に、「注文が来ました、ここに詳細があります。」Eventが公開される。出荷Applicationは、メッセージングシステムを見に行く。

 

注文の詳細を見て、メッセージを出す。「Okay、私はこの人に2箱を送信する必要があります。」その他のサービスは、注文のEventを見て必要な作業を行うことができる。

そして、Store APIはそれを心配する必要はありません。
私たちはログイン処理や(WiFIの)カバレッジマップのような即時応答が必要な部分はHTTPで行っている。

サービスが要求しているのか語っているかどうかで決まる。もし要求しているのであれば、それはおそらく、即時応答を必要としている

Challenges we've faced

microservicesの最大の課題はテストです。
通常のWeb Applicationはエンドツーエンドテストが容易である。(ウェブサイト上のどこかをクリックして、データベースの変更内容を確認するような。)

しかし、私達の場合は、アクションと最終的な結果を最終的に確認することは困難だ。
問題は、泡のように連鎖し、どこで間違ったのか?それは、我々はまだ解決していないものだ。


かわりに、可能な限り各コンポーネントを良好に作ることを焦点に当てている。
そして、それぞれのmicroserviceが契約を履行するようにしている。
「いつ処理を行い、いつ返り値を得るか」手動でそれらが満たされていることを確認する。
暗黙的であり、それをテストするための自​​動化された方法を考え出していない。

この結論は、個々のApplicationがある時点で失敗することを想定して全体のApplicationを構築する。この構造は、局部的な問題を意味し、広がることはない。

一部落ちたApplicationがあった場合、そのApplicationと依存関係する部分に影響を与えるが、他のものをブロックしない。キューのおかげで、壊れたサービスは一度中断した場所から拾うことができる

On to the next thing

だから、私たちのアーキテクチャは今のところ...のようになります。
常に改善する方法を探している。


あたなたは私達のmicroservicesへの道のりの進化を見ることができる。
私たちは違う場所へ到達出来ると思う。Fareのような私達が作成したツールをいくつか持っている。そしてそれをオープンソースとして公開したいと思う。

microservices は銀の弾丸ではない。そして、すべてを解決するものではない。しかし。Karmaで偉大な作業をしている。きっとあなたののプロジェクトでも役立つだろう。

 

GitHubのREADMEをローカルで確認する。octodownをインストール。

 

f:id:koudaiii:20150201192548p:plain


READMEを書くときによく、

GitHub Preview を使って書いていたけど、

  • 微妙にgithubとデザインが違っている
  • ネットが繋がっていないとダメ

と課題があってローカルで確認できるのに良いのないかなぁと思っていた。

上のような課題に対して、
最近では、octodownを使っている。

octodown はローカル上にhtmlを発行して、
ブラウザでREADMEを確認できる。
デザインもGithubそのもので非常に良いです。


ianks/octodown · GitHub

 

環境の前提条件

 brewを最新版にしておく

$ brew doctor
Your system is ready to brew.

 

 

必要なコンポーネントをインストール


$ brew install icu4c cmake pkg-config

octodownインストール

$ gem install octodown

Building native extensions. This could take a while...
Successfully installed nokogumbo-1.2.0
Fetching: crass-1.0.1.gem (100%)
Successfully installed crass-1.0.1
Fetching: sanitize-3.1.0.gem (100%)
Successfully installed sanitize-3.1.0
Fetching: github-markdown-0.6.8.gem (100%)
Building native extensions. This could take a while...
Successfully installed github-markdown-0.6.8
Fetching: gemoji-2.1.0.gem (100%)
Successfully installed gemoji-2.1.0
Fetching: yajl-ruby-1.1.0.gem (100%)
Building native extensions. This could take a while...
Successfully installed yajl-ruby-1.1.0
Fetching: pygments.rb-0.6.0.gem (100%)
Successfully installed pygments.rb-0.6.0
Fetching: octodown-1.0.4.gem (100%)
Successfully installed octodown-1.0.4
8 gems installed 

 確認


$ gem list octodown 
*** LOCAL GEMS ***

octodown (1.0.4)

実行


$ octodown README.md

f:id:koudaiii:20150201192225g:plain

Tips

gem install した際に、OS XのVersionアップに影響して失敗してしまうことがあるみたい。
今回は、$ xcode-select --install 実行している。


$ gem install octodown
Fetching: posix-spawn-0.3.9.gem (100%)
Building native extensions. This could take a while...
Successfully installed posix-spawn-0.3.9
Fetching: github-markup-1.3.1.gem (100%)
Successfully installed github-markup-1.3.1
Fetching: rugged-0.22.0b5.gem (100%)
Building native extensions. This could take a while...
Successfully installed rugged-0.22.0b5
Fetching: escape_utils-1.0.1.gem (100%)
Building native extensions. This could take a while...
Successfully installed escape_utils-1.0.1
Fetching: charlock_holmes-0.7.3.gem (100%)
Building native extensions. This could take a while...
Successfully installed charlock_holmes-0.7.3
Fetching: github-linguist-4.2.6.gem (100%)
Successfully installed github-linguist-4.2.6
Fetching: html-pipeline-1.11.0.gem (100%)
-------------------------------------------------
Thank you for installing html-pipeline!
You must bundle Filter gem dependencies.
See html-pipeline README.md for more details.
https://github.com/jch/html-pipeline#dependencies
-------------------------------------------------
Successfully installed html-pipeline-1.11.0
Fetching: nokogumbo-1.2.0.gem (100%)
Building native extensions. This could take a while...
ERROR: Error installing octodown:
ERROR: Failed to build gem native extension.

/Users/cs006061/.rbenv/versions/2.1.5/bin/ruby extconf.rb
checking for xmlNewDoc() in -lxml2... yes
checking for nokogiri.h in /Users/cs006061/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/nokogiri-1.6.5/ext/nokogiri... no
checking if the C compiler accepts ... yes
checking if the C compiler accepts -Wno-error=unused-command-line-argument-hard-error-in-future... no
Building nokogiri using packaged libraries.
-----
The file "/usr/include/iconv.h" is missing in your build environment,
which means you haven't installed Xcode Command Line Tools properly.

To install Command Line Tools, try running `xcode-select --install` on
terminal and follow the instructions. If it fails, open Xcode.app,
select from the menu "Xcode" - "Open Developer Tool" - "More Developer
Tools" to open the developer site, download the installer for your OS
version and run it.
-----
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers. Check the mkmf.log file for more details. You may
need configuration options.

Provided configuration options:
--with-opt-dir
--without-opt-dir
--with-opt-include
--without-opt-include=${opt-dir}/include
--with-opt-lib
--without-opt-lib=${opt-dir}/lib
--with-make-prog
--without-make-prog
--srcdir=.
--curdir
--ruby=/Users/cs006061/.rbenv/versions/2.1.5/bin/ruby
--with-xml2lib
--without-xml2lib
--with-libxml-2.0-config
--without-libxml-2.0-config
--with-pkg-config
--without-pkg-config
--help
--clean
--use-system-libraries
--enable-static
--disable-static
--with-zlib-dir
--without-zlib-dir
--with-zlib-include
--without-zlib-include=${zlib-dir}/include
--with-zlib-lib
--without-zlib-lib=${zlib-dir}/lib
--enable-cross-build
--disable-cross-build

extconf failed, exit code 1

Gem files will remain installed in /Users/cs006061/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/gems/nokogumbo-1.2.0 for inspection.
Results logged to /Users/cs006061/.rbenv/versions/2.1.5/lib/ruby/gems/2.1.0/extensions/x86_64-darwin-13/2.1.0-static/nokogumbo-1.2.0/gem_make.out

 


ありゃ、失敗した。エラーメッセージに下記書いてあるので実行。

 

To install Command Line Tools, try running `xcode-select --install` on
terminal and follow the instructions. If it fails, open Xcode.app,
select from the menu "Xcode" - "Open Developer Tool" - "More Developer
Tools" to open the developer site, download the installer for your OS
version and run it.

 

 xcode-select --install


$ xcode-select --install
xcode-select: note: install requested for command line developer tools

 nokogiriも念のため確認

$ gem list nokogiri

*** LOCAL GEMS ***

nokogiri (1.6.5, 1.6.4.1)


 もう一回gem install octodownで入りました。
 
 

なぜMicroservicesが重要なのか(Why Microservices Matter)を読んだ

Heroku | Why Microservices Matterを読んだ。

 

Microservicesについては、以下が非常にわかりやすい!!

"Microservices"を読んだ | SOTA

 

Herokuは、

The Twelve-Factor App(日本語訳)SaaSの方法論を上げている。

上記2つを合わせて読むと面白い。

Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。

・セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。

・下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。

・モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。

・開発環境と本番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。

ツールアーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 

Twelve-Factorの方法論は、

どのようなプログラミング言語で書かれたアプリケーションにでも適用できる。
また、どのようなバックエンドサービス(データベース、メッセージキュー、メモリキャッシュなど)の組み合わせを使っていても適用できる。

 

以下は、読んだ時の簡単なメモ。

Why Microservices Matter

すべての成功したアプリケーションは、時間をかけて複雑さが増す。

Developerはその複雑性に立ち向かうために、2つの戦略がある。

  • そのままチームみんなでKeepする(monolith)
  • チームを複数に分けて小さなプロジェクトを進める(Microservices)
 

■ monolith

  • 最も極端なmonolithは、ひとつのコードベース
  • すべてのアプリケーションのロジックが入りチーム全員がコントリビューター

このアプローチがもっとも自然で大体このモデルに向かう傾向がある。

これは多くの点で簡単かつ、一つのコードベースは分散システムにかかるコストを減らすことができる。 

しかし時間が経つにつれて、

  • 大きくなるプロジェクトによるDeployするコストが大きくなる
  • 大きなチームは共同作業が困難になっていく 
 

■ Microservices

  • 管理ができるように大きなプロジェクトを分解する戦略
  • 分解したプロジェクトは、書かれるべきものを見やすくする習慣を作る

この戦略へ進むことはソフトウェアがよりスケールする可能性がある。

 既に大規模なIT業界(少なくともHerokuやNetflix、Amazon)では組織的な開発の中核を担っている。

しかし、Microservicesの開発をすることで、新たな課題が存在する。

Microservicesのコンセプト

ざっくり自分たちのアプリケーションを機能毎に因数分解していくことである。

これを達成するためには、

  1. ビジネス要件ごとに分割(例:アカウント管理、広告、インターフェース)
  2. 1を提供するプログラムを書き出す
  3. 各サービスをつなげる(HTTP、AMQP、Redisのような言語に依存しない形で)
  4. 最後に、他のサービスとデータを交換するためのプロトコルを介してメッセージを渡す

 

Microservicesのメリットとして、

  • 低レイテンシのために分散することができる
  • 冗長性を確保するために、同時に同じサービスの複数のバージョンを実行することができる
  • サービスはコードによって強要されず、ビジネス単位で組織的に動くことにできる。
  • 未来の技術やインターフェースに対して対処しやすい

しかし、Microservicesは銀の弾丸ではない。

個々のサービスを固ることで複雑さを取り除く一方、

全体的には、ネットワークレベルでの分散システムの多くの課題がある。

Microservicesの可能性と課題

monolithアプリは多くの責任を一つの巨大プログラムで包括している。

Microservicesはそれぞれ単一で責任をもってプログラムを小さく構成している。

 

Microservicesを用いることで

  • エンジニアチームがサービス毎に独立して動くことができる
  • そして小さいプログラムは理解しやすく、開発者が新しくJoinしてもすぐに貢献できる

また個々のアプリケーションは独立しているため、サービス全体に対して大きなコストをかけずに変換することができる

  • 新技術が利用可能かつ、特定のサービスに有効であれば、そのサービス限定で書き換えることができる
  •  言語にとらわれないプロトコルを利用するため、アプリケーションは異なる言語で実装ができる

 

もちろん、ソフトウェアがリリースされなければ意味が無い
小さなサービスの展開は、単一のコードベースよりもはるかに大きなオーバーヘッドが発生する。

  • いくつかのサービスはロードバランサのようなものをサポートする必要である
  • monolithでも行っているProcess監視等を一つひとつ行わなくてはならない
  • 独立して様々な作業をスケールさせる必要がある
  • 各サービスは処理が異なる組み合わせのためメモリやIOの設定と監視を異なる形式で入れるべきである
  • 各サービスのスケールタイプは、ユーザの需要に適応するべきである

柔軟性、レスポンス、処理効率、サポートの面で膨大な運用コストがかかる。 

信頼できる可用性をもつPaaSの存在

PaaSはあなたのソフトウェアを抽象化させてコンテナを提供する。

 さらにコンテナの外では、ロードバランサから独立したスケールとプロセスモニタリングを含め、すべてプラットフォーム上から提供される。

 

PaaSを利用することで、

  • Deployする専任者の資格はいらない
  • Deploy自体のコスト削減(git push)
  • デベロッパーはさらにはプロジェクトマネージャのようなジェネラリストように成長する

Heroku利用者の中では、誰もが運用にフルタイムを捧げていない。

しかし、すべての開発者は世界カ国でデプロイすることができる。

PaaSの出現により、Microservicesへの展開が目指しやすくなっている。

何を意味するのか?

時間をかけてプロジェクトを拡張する方法の一部として、Microservicesへの戦略を検討した方が良い。Microservicesのオーバーヘッドは、PaaSを利用することでオーバーヘッドを下げる。

 

しかし、複数のコードベースを実行するためには運用上の課題をクリアにすることが必要である。

 さらに、各コンポーネントで監視および警告などを設定する必要がある。

 

Microservicesは個々のコンポーネントのテストとリリースを簡単にするが、

システム統合レベルでのコストが発生する。

 

サービスのいずれかが停止した場合、

他のサービスはどのように振る舞うのか?そのための計画と対策が必要である。

また、あまりにも細かくコードをアップして分割することをスタートしてはいけない

各分割点は、APIチームが時間をかけてサポートする必要がある。

まずは彼らのAPIからモバイルとウェブを分離することを開始するのが非常に賢明な場所である。

 

全体的のアプリケーションを分解する戦略は、
より良い技術の選択を行うことができ、チームがより速度を与え、可用性を維持するために、より多くの方法を与えることができる。

 

Herokuの上でMicroservicesを活用する方法の詳細は以下のYouTubeがある

Production-ready Node Architecture - YouTube

Fred George - Microservice Challanges - YouTube