Craft Conference 2015でAdrian Trenaman氏が，モノシリックなRuby on Railsアプリケーションから，Scala，Docker，AWSを活用したクラウドベースのマイクロサービスによる‘LOSA(Lots of Small Application)’プラットフォームへという，Gilt.comアーキテクチャの発展について講演した。その中で氏は，Giltがスタートアップから10億ドル企業へと発展した過去８年間に，技術面と組織面の両方から学んだ教訓を公開している。
Gilt.comの技術担当副社長を務めるTrenaman氏の講演は，Gilt Groupeが提供する中心的ビジネスとそのテクノロジの紹介から始まった。Gilt.comは，高級ブランドやライフスタイルグッズのフラッシュセールを専門とするオンラインショッピングWebサイトで，米国を基盤にしている。フラッシュセールの特徴は，Webサイトのトラフィックがセール開始の15分前に急激に上昇した後，２時間に渡って急速に低下し，低いレベルのベースラインに戻る，という動きを見せることだ。このようなトラフィックパターンの結果として，アプリケーション障害によるコストは，問題が発生した時刻に大きく左右される。
私たちのユーザは，バイソンの群れのように，毎日午後12時にサイトに殺到します。サービス拒否攻撃を毎日，自分たちから仕掛けているようなものです ...
Gilt.comのWebサイトは当初，PostgreSQLデータベースを使ったモノシリックなRuby on Railsアプリケーションとして，2007年に構築された。トラフィックの増加に伴ってmemcachedキャッシュレイヤが追加され，サイト内にあったいくつかのビジネス機能が，一連のバッチプロセスジョブに移行された。その後，4年間に及ぶトラフィックの増加がオリジナルのアーキテクチャを圧迫し始めた。さらにアプリケーションのモノシリックな構造ゆえに，どのようなクラッシュでも，Webサイトとそれをサポートするビジネスアプリケーション全体のフェールを引き起こしていたのだ。
2011年になると，Java言語とJVM(Java Virtual Machine)がアプリケーションスタックに導入され，ビジネス機能をベースとして，サービスをオリジナルのモノリスから抽出する作業が開始された。元々あった単一データベースへの依存性が取り除かれたのもこの時期だった，と氏は述べている。開発に対する投資には，必ずそれ以上の何らかのリターンがあったのだ。ただし，小規模なサービスの大部分は，プライマリデータベースのデータを読み取り専用でコピーして保持していた。'カート'サービスは，Voldemortベースのデータストアを独自に使って作られていた。
2011年当時のGiltのアーキテクチャについてTrenaman氏は，‘巨大で疎結合なJSON/HTTPサービス’と，そのサービスのバウンダリを越えて交換される，粒度の粗いキー／バリューマップとしてのデータで構成されていた，と説明している。同社が信じ難いペースで革新を続けるのに伴って，開発チームも意図しないまま，‘Swift’ビューサービスで新たなJavaベースのモノリスを開発することになり，それがイノベーションのボトルネックとなった。アーキテクチャの結果として，'重要視される部分と，そうでない部分を持った' コードベースが作り出されたのだ。
Trenaman氏は，Giltの技術的リーダシップが2011年に，戦略的イニシアティブ(いわゆる逆コンウェイ戦略)を中心としたチーム再編を決定した様子について説明した。その最大の目的は，コードの実運用投入を容易かつ迅速に行えるようにするためだ。明示的なアーキテクトという役割はなかったが，Giltの技術カルチャと価値観によって，マイクロサービスベースの 'LOSA(Lots Of Small Application)'アーキテクチャが明確になってきた。個々のイニシアティブの下で作業するチームにはそれぞれ，目標とKPI(Key Performance Indicator)が設定され，多数のイニシアティブが開始された(2015年には，マイクロサービスの数が156に達している)。
JVM上で動作するScalaが技術スタックに導入されると，マイクロサービス数の成長はさらに加速された。Trenaman氏が説明するGiltの平均的なサービスは，2,000行のコードと5つのソースファイルで構成され，運用時には3つのインスンタンス上で実行される。また2011年から2015年の間には，レガシアプリケーションをAWS(Amazon Web Services)へと“リフト・アンド・シフト”する決定も行われた。新たに開発されたマイクロサービスも，このプラットフォームにデプロイされている。Trenaman氏によると，Giltで運用しているサービスの大半は，AWS EC2のt2.microインスタンス上で実行されているという。このインスタンスは，計算能力は比較的低いものの，‘バーストに対応可能なパフォーマンス’を提供することができる。
Giltはマイクロサービスアーキテクチャに対して非常に積極的だ，とTrenaman氏は言う。同社にとって次のようなメリットがあるからだ。
- チーム間の依存関係の低減により，コードの実運用への展開が迅速になる。
- 多くの取り組みを並行して実施することができる。
- 複数の技術，言語，フレームワークをサポートする。
- サービスの穏当な低下(Graceful Degradation)が可能になる。
- '廃棄可能なコード'により，イノベーションを促進する。失敗して次に進む，という行動を取りやすくなるためだ。
Trenaman氏は同時に，マイクロサービスベースのLOSAアーキテクチャの実装には，さまざまな問題があったことにも言及している。
- 複数のチームやサービスを対象としたステージング環境の維持には困難が伴う。Giltは，例えば‘秘密のカナリア’(dark canaries)のような，運用環境でのテストが最善のソリューションである，という考え方を支持している。
- サービスのオーナシップ定義が難しい。Glitでは，サービスを所有し，維持するチームあるいは部署を選択するやり方をしている。
- デプロイの自動化が必要である。Giltでは，DockerとAWSを使ったツーリングを構築中である(その中のいくつかは，近々オープンソース公開する予定)。
- 軽量なAPIを定義する必要がある。GiltはRESTスタイルのAPIを標準化すると同時に，'AVRO for REST'と題した'apidoc'を提供している。
- エンジニアの実運用に対する自律性とコンプライアンスの両立が困難である。Giltでは同社の'CAVE(Continuous Audit Vauld Enterprise)アプリケーション内に'非常にスマートなアラート'を開発している。
- I/O爆発(explosion)回避の取り組みが必要。内部サービスの呼び出しが冗長な場合があり，同社技術チームの課題となっている。ループを自動検出することができない，というようなことだ。
- 複数サービスのデータベースにわたるレポートが難しい。Giltはイベントをひとつのデータレイク(data lake)に格納するために，リアルタイムのイベントキューを利用する取り組みを行っている。これには現在，AmazonのKinesisとS3サービスが使用されている。
Adrian Trenaman氏の講演 'Scaling Microservices at Gilt'に関する詳細は，CraftConf Webサイトで見ることができる。講演で取り上げられたGiltの技術に関しては，Gilt Techブログに詳しく紹介されている。