GiltでのScala，Docker，AWSを使ったマイクロサービスのスケールアップ

私たちのユーザは，バイソンの群れのように，毎日午後12時にサイトに殺到します。サービス拒否攻撃を毎日，自分たちから仕掛けているようなものです ...

Gilt.comのWebサイトは当初，PostgreSQLデータベースを使ったモノシリックなRuby on Railsアプリケーションとして，2007年に構築された。トラフィックの増加に伴ってmemcachedキャッシュレイヤが追加され，サイト内にあったいくつかのビジネス機能が，一連のバッチプロセスジョブに移行された。その後，4年間に及ぶトラフィックの増加がオリジナルのアーキテクチャを圧迫し始めた。さらにアプリケーションのモノシリックな構造ゆえに，どのようなクラッシュでも，Webサイトとそれをサポートするビジネスアプリケーション全体のフェールを引き起こしていたのだ。

2011年当時のGiltのアーキテクチャについてTrenaman氏は，‘巨大で疎結合なJSON/HTTPサービス’と，そのサービスのバウンダリを越えて交換される，粒度の粗いキー／バリューマップとしてのデータで構成されていた，と説明している。同社が信じ難いペースで革新を続けるのに伴って，開発チームも意図しないまま，‘Swift’ビューサービスで新たなJavaベースのモノリスを開発することになり，それがイノベーションのボトルネックとなった。アーキテクチャの結果として，'重要視される部分と，そうでない部分を持った' コードベースが作り出されたのだ。

Giltはマイクロサービスアーキテクチャに対して非常に積極的だ，とTrenaman氏は言う。同社にとって次のようなメリットがあるからだ。

• チーム間の依存関係の低減により，コードの実運用への展開が迅速になる。
• 多くの取り組みを並行して実施することができる。
• 複数の技術，言語，フレームワークをサポートする。
• サービスの穏当な低下(Graceful Degradation)が可能になる。
• '廃棄可能なコード'により，イノベーションを促進する。失敗して次に進む，という行動を取りやすくなるためだ。

Trenaman氏は同時に，マイクロサービスベースのLOSAアーキテクチャの実装には，さまざまな問題があったことにも言及している。

1. 複数のチームやサービスを対象としたステージング環境の維持には困難が伴う。Giltは，例えば‘秘密のカナリア’(dark canaries)のような，運用環境でのテストが最善のソリューションである，という考え方を支持している。
2. サービスのオーナシップ定義が難しい。Glitでは，サービスを所有し，維持するチームあるいは部署を選択するやり方をしている。
3. デプロイの自動化が必要である。Giltでは，DockerとAWSを使ったツーリングを構築中である(その中のいくつかは，近々オープンソース公開する予定)。
4. 軽量なAPIを定義する必要がある。GiltはRESTスタイルのAPIを標準化すると同時に，'AVRO for REST'と題した'apidoc'を提供している。
5. エンジニアの実運用に対する自律性とコンプライアンスの両立が困難である。Giltでは同社の'CAVE(Continuous Audit Vauld Enterprise)アプリケーション内に'非常にスマートなアラート'を開発している。
6. I/O爆発(explosion)回避の取り組みが必要。内部サービスの呼び出しが冗長な場合があり，同社技術チームの課題となっている。ループを自動検出することができない，というようなことだ。
7. 複数サービスのデータベースにわたるレポートが難しい。Giltはイベントをひとつのデータレイク(data lake)に格納するために，リアルタイムのイベントキューを利用する取り組みを行っている。これには現在，AmazonのKinesisとS3サービスが使用されている。