展開するという構成です。ここに至るまでそれなりにハマりどころ、考慮すべき点に遭遇したので今回はそのことについて書きたいと思います。1.0.4を前提としていることをご了承ください。サービス開始から20年が経ち、コードベースも次第に巨大になってきました。コードベースが巨大になるにつれて、デプロイ速度の鈍化やメンテナンス性の低下が目立つようになり、開発速度が低下していきました。移行を契機にマイクロサービス化に踏み切ります。サービスを適切な単位で切り分けてデプロイを独立化し、開発チームに権限を移譲することで分業化に成功しました。年月が経ち新たな課題が見え始めました。それはマイクロサービス化による車輪の再発明と分散システムとしての難しさです。実装することにより、従来の体制と比較して重複する機能が多くなってしまいました。加えて、下流のサービスに巻き込まれる形での障害も目立つようになり、分散したアプリケーションをうまく運用するという難しさにも直面することになったのです。導入によるマイクロサービスに必要な機能の一貫した提供でした。ようなマイクロサービスに必要な機能を提供するソフトウェアです。導入して開発コストの削減と分散システムとしての信頼性の向上を狙いました。トラフィックの質が違う複数のアプリケーションを同じインスタンスに同居させることでコストの最適化にも繋がりますし、アプリケーション間のネットワークの距離も縮まるためパフォーマンスへのインパクトも期待できるはずです。ルーティングする仕様が提案されています)github.com加えて、ベンダーロックインからの解放も期待できるということで熟考の上決断に踏み切りました。本番導入までの障壁ここからは実際に本番導入に至るまでの障壁について紹介します。導入するアプリケーションの性質に応じて慎重に導入の是非を考慮すべきです。よるオーバーヘッドについてはドキュメントにあるのでそちらをご参照ください。程度のオーバーヘッドが生じます。手元の環境でのパフォーマンステスト結果としてもほとんど同様の結果が得られました。対して複数回リクエストするとき、そのリクエスト数分だけこのオーバーヘッドが生じることになります。トラフィックに対する処理の比重が大きいという特徴があります。やめればパフォーマンスが大きく改善するということを意味します。取捨選択を行うべきです。有無に関してはアプリケーションの性質に応じて慎重に判断する必要があるでしょう。ごとにデプロイ可能なリソース量を制限する機能があります。対してリクエストするリソース量、上限まで利用できるリソース量を指定することが義務付けられるというものです。リソースを際限なく消費されると困るので一般的にこれを使って制限をかけることになります。現在ではこれに対して別途対応が必要です。指定できるので以下のようにパッチを当てます。利用量はリクエストに応じて増加するためここは随時調整します。thread/core.しかしこれだけではまだデプロイは成功しません。リソース指定が義務付けられるためこちらも対応する必要があります。ないためこちらは少々ハックが必要です。内容を解釈できるようになりました。同じようにリソースを指定するのみです。こちらは初期化処理をするためだけのコンテナなのでリソースを多く必要としません。デプロイできるようになりました。期待通りの動きをしません。コンポーネントにおけるデフォルトのリソース確保量を設定する項目があるのでそちらを調整して解決します。適切に動作するはずです。デフォルトの設定ではそれぞれのコンポーネントが1台ずつデプロイされるのみで、最大でも5台にまでしかスケールしません。これでは可用性に欠けるため適切な設定を施します。数が多いためすべての設定はしませんが以下のようなパッチを当てて台数を調整しましょう。構築しただけでは、そのまま運用を始めるには心許ないです。スケールアウトもできなければ、運用に必要なメトリクスも不足しているという状況です。コミュニティにはそれらを補うための素晴らしいソフトウェアがあるのでそれを利用しましょう。オートスケールの実現です。提供してくれているので素直にそれを利用しましょう。