カミナシ・エンジニアリングマネージャーの @dmi8a です。
先日行われた Startup Issue Gym #3【AWS活用におけるIssue】 にて「カミナシレポートが辿り着いたメンテナンスモードのあり方」というタイトルで発表してきました。
概要
カミナシは、フロントエンド: SPA（S3 + Cloudfront + etc.）、
バックエンド: API（ECS (Fargate)+ ELB + etc.）といった技術で構成されています。
SPA以外にmobileアプリも別途存在し、mobileアプリについては24h/365日利用される前提のため、 メンテナンスモードのあり方について従来より悩んでいました。
本登壇では、その悩みの末に辿り着いた、カミナシレポートのメンテナンスモードのあり方について共有させていただきました。
結論
メンテナンスモード中、Web（管理者向け）は 全操作不可とし、アプリ(現場向け)は オフラインモードにて利用可能 としました。
メンテナンスモードの設定
カミナシのインフラ構成概要は以下の通りです。
ELBのfixedレスポンス活用 + Lambda、および、MySQLのinnodbオンラインDDLを併用する事でメンテナンスモードを実現しています。
ELBのfixedレスポンス活用 + Lambda
カミナシでは、ELBのリスナールールを変更する事でメンテナンスモードを開始します。
具体的には、優先順位の最後にある行の「転送先」を事前にLambdaで作成したターゲットグループに変更します。
Lambdaに記載された固定のHTTPレスポンス内容 + statusコードを返す事でclient側にメンテナンス中と認識させます。
MySQLのinnodbオンラインDDL
最も苦慮したのが、mobileアプリの「24h/365日利用可能」という要件の達成です。
こちら達成のためには、メンテナンスモード時に行う事が多い Alter table系処理 と mobileアプリのHTTPリクエストから発行されるSQLの同時実行を達成する必要があります。
transactionを貼ったSQL処理が実行された状態で Alter table系処理を流すと、容易にDBがデッドロックされてしまいサービスが止まってしまうリスクがあるため、そのリスクをどう回避するかに頭を悩ませました。
この用件をクリアするため、innodbというストレージエンジンを利用したMySQL 5.6以上にある「オンラインDDL」という機能に着目しました。
この「オンラインDDL」がある事で、Alter table系処理でテーブル定義の変更中に、SELECT／INSERT／UPDATE／DELETEに関する処理が継続できるとされていました。
調べたところ、カラムデータ型変更、プライマリーキー削除、パーティション作成/追加/削除を除けば、Alter table系処理中でもmobileアプリからHTTPリクエストが来てSQLが発行された場合でも耐えられうる可能性がある事に気づきました。
さらに調査を進めたところ、「Waiting for table metadata lock」が発生しないか、「innodb_online_alter_log_max_size」を超えるほど処理時間の長いものが流れないか、この2点をクリアできる場合はAlter table系処理とサービスからのリクエストの同タイミングでの実行を許容できるという結論に至りました。
結果、mobileアプリのオフラインモード + メンテナンスモード時はELBに流れてくるHTTPリクエストの総量削減 + MySQLのinnodbオンラインDDLを併用、の3点を持って、mobileアプリの24h/365日利用の要件を達成しました。
注意点: データが多くなって上記手法で対処できなくなった場合
データ数が多くなってくると、検証時点でAlter table系処理時間が長すぎて失敗するようになります。 その場合は、以下の通りレプリケーションを利用するしかなくなってきます。
まとめ
現在はまだデータ数が少ないため、今回発表させていただいた手法を持ってメンテナンスモードが実現できました。 我々のように、まだスタートアップの初期フェーズ〜ミドルフェーズくらいまでであれば、リリースや検証コストが節約できると思いますので、そういった企業様に少しでも参考になれば幸いです。
最後に宣伝になりますが、カミナシでは、アプリエンジニア/SREと幅広く募集しております！
少しでも興味を持っていただいた方からのご応募お待ちしております！
