iQONリニューアル後のシステム構成について

f:id:vasilyjp:20180927090637j:plain

みなさん、おひさしぶりです、キュン(@kyuns)です。記事を書く時間がすっかり空いてしまい猛省... 先日iQONがリニューアルしました。今回から数回に渡ってリニューアルまわりの記事を書きたいと思います。まずはじめはシステムの全体的な構成についてです。今回のリニューアルでは主に以下の点に絞ってシステムの構成を見直しました。

1.EC2インスタンスの引越し

2.Ruby化

3.内部APIモデルの採用

4.検索システムの見直し

1.EC2インスタンスの引越し

今まではAmazon EC2のUS-WEST (西海岸)で運用していたのですが今回のリニューアルにあたり EC2(東京リージョン)に変更しました。もともとEC2の西海岸へはstaticなページでもレイテンシーが400ms-600msほどあり、不満がたまっていたところでした。結果的に東京インスタンスへの移行は"劇的な"パフォーマンスアップにつながりました。 HA目的以外でまだ西海岸インスタンスを使っている人は今すぐにでも引っ越しするべきです。

EBS、およびS3のデータのコピー

サーバー自体を東京インスタンスに移したことによりデータの保存先であるS3やEBSも東京リージョンに移行する必要がありました。 S3については名前を変えて新しく東京のバケットにつくりなおしました。残念なことにAWSはデータを簡単に移行できるツールなどは用意してくれていないので自前で西海岸のバケットから東京のS3バケットにコピーするスクリプトを組んで移しました。 EBSについても同様で手動でrsyncしました。このあたりの作業は非常にめんどくさいですね。 AWSももう少しデータ移行まわりを強化してほしいです。

Cloud Frontの廃止

もうひとつ、AmazonのCDNサービスであるCloudFrontの利用も廃止しました。今までは画像の配信にCloudFrontを使っていたのですが、S3のみのシステムに変更しました。 CloudFrontはとても便利なのですが、一度キャッシュされたものを削除するのが非常に手間だったのです。 AmazonCDNにはキャッシュを削除するAPIが用意されてはいるのですがそのAPIを実装したクライアントがほとんどないといっても過言ではありません。現状僕が知るかぎりではCloudberryぐらいでしょうか。（しかもWindowsのみ) S3のみに変更したことによりレイテンシーが気になることは思いますが、実際に調べてみるとCloudFront経由でS3の画像を取得した場合、一度キャッシュされた画像は平均50msでレスポンスが返ってくるのですが、S3(東京)でもほぼ同等の速度がでておりサービス運用に問題はないと判断しました。

2.Ruby化

今まではシステムのフロントエンドもバックエンドもPHPで構成されていたのですが独自のPHPフレームワークを用いており、開発人数が増えたことによりメンテナンスおよび学習コストがかかるようになっていたのでRuby on Rails化することによって複雑になっていた処理の見える化を行いました。ソースコードは全てgitで管理されており、capistranoを用いてdeploy作業を行なっています。 capistranoについては以前にこちらの記事で紹介しています。アプリケーションサーバーはRuby1.9.2 + Rails 3.0.X + Passenger で動いています。

3.内部APIモデルの採用

内部APIモデルの採用の目的としては"データの取りだしやすさ"と"スケールのしやすさ"です。近年Webアプリケーションではデータの加工部分のロジックは1箇所にまとめておいてデータのアウトプット先がiPhoneやスマホ向けサイト等複数になってもデータを取り扱いやすいようにWebAPI化しておくいわゆる「API化」が進んでいると思います。今回のリニューアルでもいわゆる内部APIモデルを採用しました。データの取得、書き込みはすべてRESTfulなAPI経由で行っています。フロントのアプリケーションサーバーにはロジックはほとんどいれずアプリケーションサーバーからAPIサーバーに対して HTTP経由で並列にデータを取得する流れになっています。

アプリケーションサーバーとAPIサーバーを切り離しているためデプロイも別々にでき、また台数も別々に増やすことができるためスケールが容易になっています。また、キャッシュサーバーとしてMemcachedとVarnishを利用しています。リアルタイム性が必要でかつデータの粒度が小さいものはmemcachedに入れておき検索や一覧など、リアルタイム性のやや低いものはVarnishでレスポンスをまるごとキャッシュしています。アイテムのデータやコーディネートの個別データなどはmemcached、検索一覧などはVarnish、といった感じです。

4.検索システムの見直し

今まではDBから検索するようにしていましたが、データ量が増え、検索したい軸も増えてきたことにより検索エンジンを用いることにしました。色々検討した結果、今回はAmebaやcookpadでも使われているSolrを使うことにしました。これについては次回以降、nakedエンジニアの@6ratsが別途解説する予定です。