こんにちは！Yakumoチームの@ueokandeです。
昨年9月、US向けにAWS 基盤のkintoneがリリースしました。 以前まではUS向けkintone (kintone.com) は日本のオンプレデータセンターから提供してましたが、このリリースによりUS内のAWSリージョンから提供が始まりました。 本日はAWS版kintone.comリリースの裏側を紹介します。
AWS版kintone.comについて
まず初めにAWS版kintone.comについて軽く説明します。
これまでのkintone.comは、日本向けkintone (cybozu.com) と同じ日本のデータセンターで運用していました。 US国内のAWSに移行することで、USのお客様のセキュリティニーズを満たしつつより高いパフォーマンスを実現できるようになります。 またcybozu.comとは独立して運用できるため、リリースによる停止時間の削減やスピーディなサービスの改善を実現できるようになります。
すでにAWS版kintone.comの提供は開始していますが、ユーザー視点で見るとリリース前後で大きな変化はありません。 運用視点で見ると、従来日本のデータセンターで運用してきた、DNSサーバーやHTTPロードバランサー (L7LB) なども、AWS上のサービスに移行します。 このリリース後も、これまでにkintone.comを利用していた客様は、引き続き日本の基盤で運用されるkintoneを利用します。 既存のお客様は今年2020年のQ2に、AWSへの移行が計画されています。 この作業が完了すると、kintone.comは日本のcybozu.comから完全に独立して運用ができるようになります。
並行運用とリリース計画
先ほども書きましたが、2019年9月から2020年Q2までの期間は、kintone.comは日本とAWS版の両方で運用されます。 そのため今年の2020年Q2までの期間は、既存のお客様のリクエストは日本で運用されているkintoneが処理します。 この仕組みを実現するために、日本・AWS両方のkintoneのリクエストを一度AWS側で受け取り、既存のお客様のリクエストを日本に転送します。
開発初期は日本の基盤と全く切り離して開発がスタートしました。 DNSサーバーやL7LBなどの運用準備が整うと、kintone.comへのリクエストをAWS側で受け取るように切り替え作業をします。 もちろんこのリリースでは、既存のお客様への影響は最小限にする必要があります。 これらのリリースの手順を説明します。
ビッグバンリリースを避けろ！
リリースの影響や切り戻しの規模を最小限にするため、ビッグバンリリースは極力避けるべきだと言われています。 AWS版kintone.comのリリースには、日本側の切り替え作業も発生します。 リリースに失敗すると、新規のお客様だけではなく既存のお客様も利用できなくなるなどの影響が出る可能性もあります。 そのためAWS版kintone.comのリリースは慎重に進められました。
AWS版kintone.comのリリースは、7月、8月、9月の3回に分けてリリースをしました。 9月にAWS版kintone.comのサービス提供が開始したのは事実ですが、実は7月からすでにAWSの運用は開始していました。 それぞれのリリースでは以下の切り替え作業をしました。
- 7月: DNSサーバーの移行
- 8月: L7LBの切り替え
- 9月: AWS上で新規お申し込みの受付
各リリースでYakumoチームはどういう対応をしたかを順に説明します。
7月: DNSサーバーの移行
まずはDNSサーバーの切り替えです。 このリリースでは、これまで日本のオンプレデータセンターで運用していたDNSサーバーの一部を、AWSのRoute 53に移行します。
この時点ではまだ、kintone.comは日本のデータセンターで運用されています。 Route 53は***.kintone.comというドメイン名に対して、日本のIPアドレスを返します。
DNSサーバーの移行は以下の手順で行いました。
- 即座に反映・切り戻しを行えるように、日本のDNSサーバーのTTLを短くする。
- Route 53であらかじめ***.kintone.comに該当するDNSレコードを登録する。名前解決されたIPアドレスは日本のデータセンターを指す。これも短いTTLを設定する。
- kintone.comのNSレコードを、日本のネームサーバーからRoute 53のネームサーバーに変更する。
- しばらく待ってRoute 53で設定したTTLを長くする。
これらの作業を順に適用しました。 DNSは効率化のためにキャッシュされるので、設定の変更が確実に反映されるために、TTL以上の期間待つ必要があります。 開発環境も含めて実際の切り替え作業は数日ほど要しましたが、お客様への影響はありませんでした。
8月: L7LBの切り替え
続いてはL7LBの切り替えです。 日本に到達していたkintone.comへのリクエストを、AWSのALB (Application Load Balancer) が受け取るようにします。 AWS版kintone.comは、ALB内部に更にNGINXをつかって、既存のお客様のリクエストを日本に転送します。 NGINXはリクエストのFQDNから、既存のお客様かAWS版kintone.comのお客様かを判断します。
この作業では、Route 53の***.kintone.comに対するアドレスを、日本のデータセンターからAWSのALBに変更します。 すでにDNSサーバーはRoute 53に移行済みなので、Yakumoチーム内だけで切り替えと切り戻しができるようになりました。
AWS版kintone.comの提供は開始してませんが、すでにNGINXやFQDNの管理に必要なミドルウェアが、Amazon EKS (Elastic Kubernetes Service) 上で運用されています。 このリリースから、Yakumoチームのオンコール体制も始まりました。 ミドルウェアやEKSに障害が発生すると、既存のお客様にも影響がでるので、Yakumoチームが速やかに障害対応する必要があるためです。
9月: 新規お申し込みの受付
さていよいよAWS版kintone.comのリリースです。 実はこのリリースはこれまでのリリースと比較すると、Yakumoチームの作業はほぼ発生しませんでした。 このリリースでは、kintoneのお申し込み画面 (https://www.kintone.com/trial/) からのリクエストを、国内からAWS上のシステムに変更します。 これで晴れて、新規のお客様は無事、AWS版kintoneを利用できるようになりました。
まとめ
AWS版kintone.comのリリースの裏側と、日本のkintoneの並行運用について紹介しました。 お客様への影響を最小限にするため、お客さんへの提供を始める前にから、裏ではこまめなリリースを実施してきました。
現在Yakumoチームは、Q2の既存のお客様をAWSに移行するための準備をしています。 この移行作業が完了すると、US向けのkintoneは完全に日本のデータセンターと独立して運用できます。 しかしミドルウェアの設計が異なるので、データコピーだけでなくそのマイグレーション作業も発生します。 移行作業やマイグレーションについてもお話できることはいくつもあるので、kintone移行後にまた改めて記事を書きたいと思います。
