STORES Tech Blog

こだわりを持ったお商売を支えるプラットフォーム「STORES」の開発チームによる技術ブログです。

こだわりを持ったお商売を支えるプラットフォーム「STORES」の開発チームによる技術ブログです。

STORES EC のインフラ構成

はじめに

STORES で EC サービスの SRE エンジニアをしている秋元と申します。

hey アドベントカレンダー 2020 の 3 日目の記事です!
今回は STORES EC のインフラ構成を紹介したいと思います。

正直なところ、弊社のインフラ構成は「すごく最先端を走っていて、これからサービスを作っていく上で非常に参考になる!」といったものではありません。 レガシーな部分も少なからず(?)残っていて、そういった部分を改善していくタスクも少なくはありません。

こういった情報をオープンにする理由としては、採用のミスマッチを少なくしたいためです。
採用面接などで誤魔化して良く見せて入社してみたらビックリ、みたいなことになってしまうとお互いにいいことはないように思います。 また一方で、こういったどんどん改善していくようなフェーズの面白さもあると思うので、それを感じていただけるような方に来ていただけるとありがたいと思っています。

インフラ構成

インフラ構成はこのようになっています。

f:id:akmtr:20201202184905p:plain
インフラ構成

インフラは AWS 上に構築されています。

弊社の EC のサービスは、「自分でつくれる、本格的なネットショップ」というサービスです。

stores.jp

ですので、システムとしては大きく分けて

  • ネットショップの利用者向けシステム
  • ネットショップのストアオーナー向けシステム

の二つからなっています。

ネットショップの利用者向けシステム

構成

利用者向けのシステムはマルチテナントの構成になっています。 つまり、複数のネットショップが同じインフラリソースを共有しています。

リクエストを受ける流れは、下記のようになっています。

ブラウザ → ELB → Nginx → アプリケーション(Ruby on Rails)

ELB

利用者向けのシステムでは ALB (Application Load Balancer) と CLB(Classic Load Balancer)を併用しています。 これはひとつのインフラで多くのドメインを扱う必要があるためです。

EC のサービスにはフリープランとスタンダードプランの二つの料金プランがあります。 フリープランだとネットショップのドメインxxxx.stores.jpxxxx は選択可能)となるんですが、スタンダードプランだと独自ドメインが使えるため、.com.net.shop の中からドメインを決められるようになっています。

インフラはマルチテナントな構成のため、ひとつのインフラで非常に多くの TLS 証明書を管理し、リクエストごとに適切な証明書を割り振っていく必要があります。
そこで、 xxxx.stores.jpドメイン独自ドメインでリクエストを受ける ELB を別にし、xxxx.stores.jpドメインの方は TLS 終端を ALB で行い、独自ドメインの方は TLS 終端を Nginx で行うようにしています。
ALB だと TLS 終端を行う場合はもちろんですが、 SSL パススルーができないので HTTPS で来たリクエストをそのままターゲットグループに HTTPS で流しても証明書を ALB にすべて設定する必要があります。 しかし証明書が非常に多くすべて設定することができないので、独自ドメイン側は TLS 証明書を設定する必要がない CLB を使用しています。

CLB を使っている部分については NLB (Network Load Balancer) を使うことも可能かと思いますが、こちらは今後の改善タスクの一つです。

独自ドメイン側の TLS 証明書は S3 で管理しています。 毎回 S3 から取得すると処理に時間がかかってしまうので、一度取得した証明書は Redis でキャッシュするようにしています。

アプリケーションのホスティング

アプリケーションは EC2 インスタンス上にデプロイされて動作しています。 こちらは、環境を簡単に作り直したり追加したりできるようするためコンテナ化を進めている状況です。

データベース

メインのデータベースには MongoDB を使用しています。
一般的には RDB を使うケースも多いと思いますが、MongoDB を使うのって実際のところどうなの?というところはこちらの記事にいろいろと記載があるので、ご興味がある方がいましたら是非読んでいただければと思います。

tech.hey.jp

MongoDB 以外には、検索の機能で Elasticsearch を使用していたり、キャッシュとして Redis を使用していたりします。

ネットショップのストアオーナー向けシステム

構成

ストアオーナー向けのシステムのリクエストを受ける流れは、下記のようになっています。

ブラウザ → CloudFront → S3 
ブラウザ → CloudFront → ELB → Nginx → アプリケーション(Ruby on Rails)

ストアオーナー向けのシステムの一部は SPA になっていて、js や css などの静的なファイルは CloudFront を介して S3 から配信しています。

アプリケーションのホスティング

利用者向けのシステム同様、アプリケーションは EC2 上にホスティングされています。

データベース

利用者向けのシステム同様、メインデータベースには MongoDB を使用し、検索やキャッシュなどで Elasticsearch、Redis を使用しています。

最後に

いかがでしたでしょうか?
「技術の最先端を行きたい!」という方には少し物足りないかもしれませんが、「裁量を持ってどんどん改善して行きたい!」という方には改善ポイントがたくさんあるので楽しんで働ける環境かと思っています。

明日はバックエンドエンジニアの @zakky から Ruby のカスタム例外をちゃんと使おうと思った話をお届けする予定です! これまでの記事は こちら から確認できます。

また、SRE チームでは積極的に採用をしています! 興味も持った方がいましたらこちらもご覧になっていただけるとありがたいです。

hello.hey.jp