20211209_カミナシレポートが辿り着いたメンテナンスモードのあり方

2021/12/9に開催された「Startup Issue Gym #3【AWS活用におけるIssue】」での登壇資料です。

Transcript

1. カミナシレポートが辿り着いた
 　　　　　　　　メンテナンスモードのあり方
 株式会社カミナシ エンジニアリングマネージャー 　　　 　　　　　 宮本 大嗣
2. アジェンダ 1. カミナシのサービス紹介 2. カミナシレポートのメンテナンスモードのあり方
3. 1.カミナシのサービス紹介
4. 　日本の就業人口の半分はノンデスク 設備・清掃 旅客・運輸 建設 福祉施設 製造業 スーパー・小売 接客業 飲食店 現場で働く3,100万人が、紙中心で非効率なオペレーションに日々追われています。 プライベートではスマートフォンを使っているのに、職場ではなぜか紙とペン、デジカメを使う必要があるのが現状です。 日本における労働人口の割合 デスク ワーカー ノンデスク ワーカー ％ ％ 52 48 ※ 独立行政法人労働政策研究・研修機構「職業別就業者数」より当社算出
5. まだまだ紙が主役 　製造現場のリアル
6. ◯×チェック表 紙のチェックリスト（ワークフロー） カミナシでデジタル化 ノーコードで現場管理アプリを作ることができる 　業務フローをデジタル化する
7. 条件分岐 繰り返し 多様なデータ型 　ノーコードだけど、痒い所に手が届く
8. 2. カミナシレポートの メンテナンスモードのあり方
9. 　前提 ▪Web（管理者向け） 　1日2時間程度利用できないのは事前連絡すれば許容 ▪アプリ(現場向け) 　24h/365日利用できるのが必須
10. 　結論 ▪Web（管理者向け） 　（メンテナンスモード中）全操作不可とした ▪アプリ(現場向け) 　（メンテナンスモード中）オフラインモードにて利用可能とした 1. リクエスト失敗&offlineに保存 2. onlineになったら offlineデータupload
11. カミナシ アプリ 　インフラ概要 Cloud Front S3 Bucket ELB ECS Cluster Fargate Container ・・ ・ Aurora MySQL
12. カミナシ アプリ 　メンテナンスモード中 Cloud Front S3 Bucket ELB ECS Cluster Fargate Container ・・ ・ Aurora MySQL 全HTTPリクエスト を拒否 LogInとオフライン で必要なGET処理 のみ許可
13. カミナシ アプリ 　メンテナンスモード中 Cloud Front S3 Bucket ELB ECS Cluster Fargate Container ・・ ・ Aurora MySQL 全HTTPリクエスト を拒否 LogInとオフライン で必要なGET処理 のみ許可 Lambda 許可分以外のHTTPリクエスト が来たらLambdaで事前設定 した内容をレスポンス
14. カミナシ アプリ 　メンテナンスモード中 Cloud Front S3 Bucket ELB ECS Cluster Fargate Container ・・ ・ Aurora MySQL 全HTTPリクエスト を拒否 LogInとオフライン で必要なGET処理 のみ許可 メンテナンス画面を 表示 通常操作は出来るが オフラインに作成・更 新dataが貯まる Lambda 許可分以外のHTTPリクエスト が来たらLambdaで事前設定 した内容をレスポンス
15. カミナシ アプリ 　メンテナンスモード中 Cloud Front S3 Bucket ELB ECS Cluster Fargate Container ・・ ・ Aurora MySQL LogInとオフライン で必要なGET処理 のみ許可 通常操作は出来るが オフラインに作成・更 新dataが貯まる Lambda 許可分以外のHTTPリクエスト が来たらLambdaで事前設定 した内容をレスポンス メンテナンス画面を 表示 全HTTPリクエスト を拒否
16. 　ELBのfixedレスポンスを利用
17. 　ELBのfixedレスポンスを利用 check優先順位。1番から順にcheck。 条件に合致しない場合は次の行を check。
18. 　ELBのfixedレスポンスを利用 mobile用の許可対象のリクエスト。 1行あたり4つまでしかパス設定できな いため複数行にわたっている
19. 　ELBのfixedレスポンスを利用 メンテナンスモード時変更箇所。 「転送先」を事前にLambdaで作成した ターゲットグループに変更。
20. 　ターゲットグループ with Lambda
21. 　ターゲットグループ with Lambda Web側は、statusコード:503を条件にメンテナンス画面表示 (errorsの文言を表示)
22. 　ターゲットグループ with Lambda Web側は、statusコード:503を条件にメンテナンス画面表示 (errorsの文言を表示)
23. 　ターゲットグループ with Lambda 環境変数によってメンテナンス画面の文言を自由に変えれるようにしている
24. 　メンテナンス画面
25. カミナシ アプリ 　メンテナンスモード中 Cloud Front S3 Bucket ELB ECS Cluster Fargate Container ・・ ・ Aurora MySQL 全HTTPリクエスト を拒否 メンテナンス画面を 表示 Lambda 許可分以外のHTTPリクエスト が来たらLambdaで事前設定 した内容をレスポンス 通常操作は出来るが オフラインに作成・更 新dataが貯まる LogInとオフライン で必要なGET処理 のみ許可
26. カミナシ アプリ 　メンテナンスモード中 Cloud Front S3 Bucket ELB ECS Cluster Fargate Container ・・ ・ Aurora MySQL 全HTTPリクエスト を拒否 メンテナンス画面を 表示 Lambda 許可分以外のHTTPリクエスト が来たらLambdaで事前設定 した内容をレスポンス 通常操作は出来るが オフラインに作成・更 新dataが貯まる LogInとオフライン で必要なGET処理 のみ許可 MySQLのinnodb オンラインDDL 併用にて対処
27. ▪データ定義言語（DDL: Data Definition Language） データベースのテーブルなどの作成や削除、各種設定を行う言語 CREATE(テーブル新設)／ALTER(テーブル定義変更)／DROP(テーブル削除)など ▪データ操作言語（DML: Data Manipulation Language） 既存テーブルのデータについてCRUDを行う言語 SELECT(検索)／INSERT(追加)／UPDATE(更新)／DELETE(削除)／EXPLAIN(実行計画)など ▪トランザクション制御言語（TCL: Transaction Control Language） トランザクションの開始や終了を行う言語 COMMIT(トランザクションを確定)／ROLLBACK(トランザクション取り消し)など ▪データ制御言語（DCL: Data Control Language） DMLやDDLの利用に関する許可や禁止を設定するための言語 GRANT(アクセス権付与)／REVOKE(権限破棄)など データベース言語(SQL)体系について
28. ・MySQL5.6 から「オンラインDDL」の機能が実装されました。 ・Alter table系処理でテーブル定義の変更中に、SELECT／INSERT／UPDATE／ 　DELETEに関する処理が継続できるようになりました。 MySQLのinnodbオンラインDDL機能 短時間ならAlter table系処理実行中にサービスからリクエスト来てもOKでは...? メンテ時間は2h前後取っているが、全時間Alter tableを実行するわけではない。 　index貼ったりする処理も数分程度。貼った後の検証とかに時間がかかる。
29. ・MySQLの公式ページ見ると全Alter table系処理には対応していませんでした (残念) ・以下以外のAlter table系処理なら大丈夫そう 　カラムデータ型変更、プライマリーキー削除、パーティション作成/追加/削除 MySQLのinnodbオンラインDDL機能 詳細: https://dev.mysql.com/doc/refman/5.6/ja/innodb-create-index-overview.html 並列DMLを許可が「はい」の 操作なら大丈夫 <参考> Alter table系処理に 「ALGORITHM=INPLACE, LOCK=NONE」 オプションをつけて実行し、 オンラインDDL可能か checkする手法が有名
30. <注意点1> show full processlist して ”Waiting for table metadata lock”が無いかcheck。 <注意点2> MySQLのパラメーターに「innodb_online_alter_log_max_size」がある。 (ALTER TABLE中にINSERTなどの更新情報を一時保管する上限数) このサイズを超えるSQLが発行された場合、ALTER TABLEが失敗するので注意。 MySQLのinnodbオンラインDDL機能
31. 本日は深くは言及しませんが...以下実施 1. DBクラスターにレプリケーションDB準備 + Alter table実施 2. 現行DBのBinログを使ってAlter table後のレプリケーション先にレコード復元 3. 新旧DBにて同じ状態にしたら新旧DBを切り替え 検証時にAlter tableが失敗したら
32. ・Mobileは24h/365日の操作を可能とするためオフラインモードを準備する ・Webは全操作禁止、Mobileは一部操作を許可し、HTTPリクエストを激減させる ・MySQLのinnodbオンラインDDLを併用する ・(念のため) Alter table系処理の際、show full processlist コマンドを使って、 ”Waiting for table metadata lock”しているものが無いかcheckし万全の対策をとる まとめ
33. アプリエンジニア/SRE 積極採用中