トップ > Coincheckのシステム構成 - Webアプリケーションの裏側

Coincheckのシステム構成 - Webアプリケーションの裏側

 

この記事はコインチェック株式会社のアドベントカレンダー20日目の記事です。  
 

 qiita.com

 

 

はじめに

システムインフラストラクチャ部のHagiwaraです。
「暗号資産交換所のシステム」というと、ブロックチェーンなどの特殊な技術が中心にあるイメージを持たれることもあるのですが、実はユーザーの皆様が利用する販売所や取引所、NFTマーケットプレイスといったプラットフォーム機能の裏側は、堅牢性を重視した王道のWebアプリケーションとして構築されています。
また、CoincheckのシステムはそのすべてがAWS(Amazon Web Services)上で動作しており、クラウドネイティブな構成で高い可用性と拡張性を実現しています。
創業から10年以上積み上げられてきたコードベースと、相場の変動によるアクセス増減に対応するためのインフラ構成。今回は、SREの視点からCoincheckのシステムについてご紹介します。
また、本記事では暗号資産の入出金といったブロックチェーン固有の領域はあえてスコープ外とし、あくまでWebアプリケーションとしてのCoincheckのアーキテクチャにフォーカスします。

Webサービス部分を中心とした概略図

Webサービス部分を中心とした概略図

相場変動時のスパイク負荷への対応

インフラを運用する上で最も特徴的なのが、相場変動に伴うアクセスの急増です。 価格が大きく動いた際、短時間でトラフィックが数倍に跳ね上がることが日常的にあります。この負荷変動に対して、サービスを安定して提供し続けることが最優先事項となります。
そのため、EC2のAuto Scaling Group(ASG)やフロントエンドで採用しているECS Fargate等のオートスケーリング設定、リクエストを受け付けるサーバ内での処理等においては、いくつかの工夫を行っています。

  • オートスケーリングにおけるCPUターゲットの設定(弾力性の確保)

    • 通常、コスト効率を考えるとCPU使用率は高めに設定されることが多いですが、Coincheckでは急激なスパイクが発生した際にも安定したサービス提供を継続できるよう、十分なバッファを確保したオートスケーリング閾値を設定しています

    • これは、急激なスパイクが発生した際、コンテナの起動・追加が完了するまでのバッファを確保し、可用性を維持するための設計です

  • フロントエンドでの処理の軽量化とRate Limit

    • フロントエンドサーバは「レスポンスを素早く返すこと」を最重要視しており、重い処理は即座に非同期ジョブ(Job Queue)へ流す設計を徹底しています

    • また、ブラウザやモバイルアプリと比較して相対的に数が多いAPIリクエストに関しては、WAFだけに頼るのではなくアプリケーション側でRedisを利用したAPIリクエストのRate Limit（レート制限）を行うことで 、突発的な過負荷からバックエンドシステムを保護しています

観測と監視(Observability)

システムの状態を把握するための監視基盤には、標準的なツールを選定しています。

  • Logging: （概略図では省略していますが、）各EC2やコンテナではFilebeatを利用し、ログ収集サーバであるLogstash へ転送、S3等へ集約する構成です。一部Fluentdから直接S3へログを転送する仕組みも採用しています

  • Monitoring: 全社的にDatadogを採用しており、インフラのメトリクス監視からAPMまでを一元管理しています

  • On-Call: インフラ領域の対応はSREが担いますが、アプリケーションレベルのエラーやパフォーマンス監視については各開発チームもダッシュボードやモニター整備し、対応する体制をとっています

アプリケーションとインフラの構成

システムはAWS東京リージョン(ap-northeast-1)に構築されています。可用性を高めるため、一部のコンポーネントを除いてMulti-AZ構成を採用しています。

  • Frontend

    • 従来のRuby On Railsのビューが多く使われていますが、Next.jsを利用した構成へ順次移行しています。Next.jsに関しては、CodePipeline等を利用し、1日に複数回のデプロイが行われています

  • Backend & Operations

    • メインのバックエンドは Ruby on Rails で動作しています。CodeBuildやCodeDeployなどを利用し、1日に複数回のデプロイが行われています

    • 運用面では、統制が厳しい中、セキュリティ向上とトイル削減のため、AWS Systems Manager の RunCommandやAutomation、Session Manager を中心とした運用となっています

    • WebSocket通信をハンドリングするサーバではNode.jsやDenoを採用しています

  • Database

    • データストアにはAmazon Aurora MySQLを利用しています

    • 本番トラフィックを処理するクラスタとは別に、廃止予定ではあるものの集計処理（OLAP的な用途）を行うために定期的にAmazon Aurora Fast Database Cloningを実行し、本番DB Clusterをクローンして処理を行っています

    • これにより、分析系のクエリが本番のオンライントランザクション(注文処理など)のパフォーマンスを劣化させるリスクを排除しています

非同期処理による負荷分散

販売所や取引所では、注文、約定、決済など、データベースへの書き込みを伴う処理が多数発生します。これらをWebサーバのリクエスト内で同期的に処理するとレスポンス低下やタイムアウトの原因となるため、非同期処理(Job Queue)を積極的に活用しています。

  • 非同期処理(job)の種類

    • Sidekiq: 非同期処理やスケジュールジョブなど、さまざまな処理に利用しており、Coincheckのシステムの中核を担っています

    • delayed_job: こちらは歴史的な経緯で利用が続いており、現在も一部のジョブで稼働しています

  • 役割ごとの分割

    • 注文系、決済系のように、処理の内容に応じてキューとそのワーカー、またサーバ自体もある程度のまとまりを持って分割しています。特定の処理で遅延が発生しても、他の重要な処理へ影響が広がらないように考慮しています

インフラ観点の課題とそれに向けた取り組み

現行の構成で安定稼働を続けていますが、安全性や保守性の向上、将来的なさらなるトラフィック増加や、より高い書き込み性能(Write Performance)への要求に応えるため、アーキテクチャのアップデートを検討しています。
現在は以下のような技術検証を進めています。

  • Railsが稼働する基盤をEC2 → ECSへ移行

    • 現在Coincheckシステムの大部分であるRuby On Railsは全てEC2上で稼働しております。コンテナ化を行うことで、現行と比較しても安全性・保守性・開発生産性・スケーラビリティなどさまざまな観点でメリットを享受できるためEC2 → ECSへの移行作業を実施しています

  • NewSQLへの移行検討

    • 本番データベースであるAmazon Aurora の次を見据え、RDBの堅牢さと水平スケーラビリティを併せ持つ、NewSQL/分散SQLデータベースの導入可能性についてフィージビリティスタディを行っています

最後に

Coincheckのシステムは、Webアプリケーションとして標準的な技術スタックをベースにしつつ、金融サービスとしての堅牢性と、急激な負荷変動に耐える弾力性の両立を目指して運用されています。
今回はWebアプリケーションとしての側面にフォーカスしましたが、Coincheckのシステムには、まだまだ語りきれない(あるいはブログでは書ききれない)技術的な深淵があります。
金融・上場企業として求められるセキュリティや監査統制、または法規制といった厳しい制約の中で、いかにしてセキュアかつ効率的に運用を行えるように環境を作っているかなど、金融サービスならではの難しさであると同時に、エンジニアとしての技術力が最も試される「泥臭くも面白い」領域です。
「Webアプリとしての構成はわかったけど、セキュリティの裏側はどうなってるの？」 「統制と効率化のバランス、ぶっちゃけどうやって取ってるの？」
そんな疑問を持たれた方は、ぜひカジュアル面談でお話ししましょう。ブログには書けない現場のリアルな工夫や、現在進行形の課題について、できる限りお伝えいたします！
既存のシステムを安定稼働させながら、次の10年を支える新しいアーキテクチャへの移行も並行して進めています。大規模なトラフィックを扱うインフラ構築や、信頼性の高いシステム設計に興味があるエンジニアの方とお話しできることを楽しみにしています。