さくらのセキュアモバイルコネクトの運用に CD の仕組みを導入する話

Transcript

1. さくらのセキュアモバイルコネクトの
   運用に CD の仕組みを導入する話
   2023/02/16　開発本部　佐藤 哲也
   

   View Slide

2. 自己紹介
   名前：佐藤 哲也
   所属：開発本部 モバイル開発グループ
   ※ さくらインターネットから出向
   ここ最近の活動：
   　・CNTOM 2022 でシステム運用について発表しました。
   　　URL：https://cntom.jp/program_detail/#s15
   

   View Slide

3. 本日のお話
   さくらのセキュアモバイルコネクトのモバイルコアシステム運用に
   CD（継続的デリバリー） の仕組みに導入することにした。
   導入に関する以下のことを中心にお話します。
   　・本番デプロイで失敗しないため、実現したかった２つのこと
   　・最終的にどんなシステムとなったのか（社内プルリクこれからです）
   ※ システム管理・メンテナンスの話が中心です。サービス自体の話は割愛します。
   　 参考：さくらのセキュアモバイルコネクトの紹介 URL：https://iot.sakura.ad.jp/sim
   

   View Slide

4. そもそも CD（継続的デリバリー）とは
   ・CI（継続的インテグレーション ）
   　　→ 共有されたメインラインにマージ
   　　→ 自動ビルド・自動テスト
   ・CD（継続的デリバリー）
   　　→ アプリケーションをいつでもデプロイできる状態にする（直前の状態）
   　　→ 上記実現のため、開発環境に自動デプロイメント・自動システムテスト
   ・継続的デプロイメント
   　　→ 本番環境に自動デプロイメント
   

   View Slide

5. 現在のさくらのセキュアモバイルコネクトの運用
   CI は整備されているが、デプロイ作業は手動
   　→ 本番環境＆開発環境ともに対象サーバに SSH ログイン & コマンドコピペ
   　→ 本番環境へのデプロイは上記 + Wチェック
   　→ コンフィグファイル等は一元管理されていない状態
   ※ サーバはさくらのクラウド（IaaS）上に構築
   < Github >
   download
   コンポーネントのリポジトリ
   ssh & コマンドコピペ
   作業端末
   開発環境
   本番環境
   

   View Slide

6. 現行の運用に CD を組み込むメリット
   CD を実現する過程で様々なことが整備される
   　→ 各サーバの構成情報を Ansible Playbook として管理
   　　　→ Playbook をリポジトリで管理することで一元化可能
   　　　→ 本番デプロイを１コマンドで完了できる
   　→ デプロイ後の動作は、開発環境で検証済み
   ansible-playbook
   < Github >
   download
   コンポーネントのリポジトリ
   作業端末
   開発環境
   本番環境
   Playbook のリポジトリ
   自動デプロイ
   CD 処理
   トリガーとなるイベント（プッ
   シュ・マージ）
   

   View Slide

7. では、その自動化の仕組みは
   本番メンテ時に期待した動作をするのか？
   

   View Slide

8. 完璧な Playbook を作ることの難しさ
   過去の API サーバのメンテで一度だけ Ansible Playbook を利用
   　→ 実行ファイルの差し替えは無事成功
   　→ しかし、NTP クライアントが止まってしまった
   やってみた感想： Ansible は怖い。
   

   View Slide

9. 「Ansible は怖い。」と思った理由
   Ansible Playbook を採用
   　・一回限り・一方通行のシェルスクリプトより相対的に複雑になる
   　　　→ 冪等性を意識した記述
   　　　　　→ 一方通行のスクリプトより記述量が増える
   　　　　　→ Ansible 特有の構文を理解する必要がある
   　・開発環境でのテストは適切だったか？
   　　　→ 本番環境で実現すべきことは「状態 A を状態 B にする」なのに、
   　　　→ 開発環境でのテストは「状態 A’ を状態 B にする」だったりしてないか
   完璧な Ansible Playbook を一発で書けるのだろうか
   

   View Slide

10. 完璧じゃない Ansible Playbook に備える
    ・普段から本番デプロイ相当のオペレーションに慣れておく
    　→ 開発環境へのデプロイ作業で本番相当の操作を行う
    ・以前の状態で何度でもテストできる
    　→ 各環境（主に開発環境）をある時点の状態に戻せるようにする
    一般的な CD の定義にとらわれず、上記のことを容易に実現できる仕組みを整えること
    にした。
    

    View Slide

11. ①：開発環境へのデプロイ作業で本番相当の操作を行う
    本番デプロイまでにデプロイする機会は何度もある
    　１．動作検証デプロイ（期待する動作を確認するまでデプロイ）
    　２．Approve 後のデプロイ（本番に適用する実行ファイルの動作確認）
    　３．本番環境へのデプロイ
    本番デプロイ
    Approve後の
    デプロイ
    動作検証
    デプロイ
    （N 回目）
    動作検証
    デプロイ
    （1 回目）
    ‥‥‥
    開発環境へのデプロイ 本番環境へのデプロイ
    

    View Slide

12. ②：以前の状態で何度でもテストできる
    「改修前と改修後」の２つ環境情報を用意して切り替えできる仕組みを
    改修前（現在）の環境情報
    開発 PGW-C ver1.2.3
    本番 PGW-C ver1.2.3
    開発 HSS ver2.4.5
    本番 HSS ver2.4.5
    Playbook ver3.6.7
    改修後の環境情報
    開発 PGW-C ver1.2.4
    本番 PGW-C ver1.2.4
    開発 HSS ver2.4.5
    本番 HSS ver2.4.5
    Playbook ver3.6.8
    開発環境 本番環境
    

    View Slide

13. デプロイ操作はこのぐらいシンプルに
    デプロイする環境（dev or prod）を選択
    実行する Playbook を選択
    ※ Playbook はコンポーネントごとに用意
    【 update xxx を選択 】
    　→ 改修後の Playbook / 実行ファイルが選択
    【 revert xxx を選択 】
    　→ 改修前の Playbook / 実行ファイルが選択
    Web 画面で操作を完結させる。
    

    View Slide

14. ここまでのまとめ
    ・過去の経験（反省）から以下の方針を採用
    　→ （教科書的ではないが）開発・本番ともに同じデプロイ方法にする
    　→ 改修前後の状態を行き来きできるようにする
    上記２つをシンプルな操作で実現できる実装を！
    

    View Slide

15. ここからは実装の話
    

    View Slide

16. 取り入れた技術
    　1. デプロイ操作時に簡易な Web 入力フォームを提供するため
    　　→ Github Actions Workflow（dispatch） を採用
    　2. 改修前 / 改修後の各環境の状態（定義）を表現するため
    　　→ git のブランチの動作、git submodle を採用
    【利便性を向上させる取り組み】
    　3. デプロイ作業の証跡を残すため
    　　→ Pull Request を利用
    　4. デプロイ前の作業が増えてきたため
    　　→ 初期セットアップも Github Actions Workflow を利用
    

    View Slide

17. 1. Github Actions Workflow による入力フォーム
    

    View Slide

18. CD 用リポジトリ（今回新規作成）
    2. 改修前後の状態を表現するため git の仕組みを採用
    改修前後の状態
    　 → git submodule を保持するリポジトリのブランチを管理することで実現
    master （改修前） ブランチ 改修後 ブランチ
    開発 PGW-C @ 99c4fc5
    本番 PGW-C @ 99c4fc5
    開発 HSS @ 15899f2
    本番 HSS @ 15899f2
    Playbook @ b85e456
    開発 PGW-C @ 15899f2
    本番 PGW-C @ 15899f2
    開発 HSS @ 15899f2
    本番 HSS @ 15899f2
    Playbook @ f7e1beb
    

    View Slide

19. 3. デプロイ作業の証跡を残すため Pull Request を利用
    Ansible の実行ログを参照
    実行後のサーバ状態（どの時点の Playbook の状態にあるか）を表示
    

    View Slide

20. 4. 初期セットアップも Github Actions Workflow を利用
    初期セットアップ
    　・ CD 用リポジトリにメンテナンスブランチを新規作成
    　・ メンテ対象の submodule を更新
    　・ メンテナンスブランチに紐づく PR を生成
    

    View Slide

21. デプロイ作業フロー まとめ
    やること Web UI
    操作
    Pull Request に
    投稿されるコメント
    ブランチ状態 master ブランチ
    の状態
    メンテ ブランチ
    の状態
    本番/開発環境
    の状態
    初期
    ↓
    セットアッ
    プ
    ↓
    ↓
    デプロイ
    ↓
    クローズ
    PGW-C v1.2.3
    HSS v2.4.5
    PGW-C v1.2.4
    HSS v2.4.5
    PGW-C v1.2.3
    HSS v2.4.5
    PGW-C v1.2.3
    HSS v2.4.5
    PGW-C v1.2.4
    HSS v2.4.5
    PGW-C v1.2.4
    HSS v2.4.5
    PGW-C v1.2.4
    HSS v2.4.5
    PGW-C v1.2.4
    HSS v2.4.5
    PGW-C v1.2.3
    HSS v2.4.5
    PGW-C v1.2.3
    HSS v2.4.5
    

    View Slide

22. 実装の話 まとめ
    ・以下を実現するためシンプルな操作が可能な UI を用意
    　→ 開発・本番ともに同じデプロイ方法
    　→ 改修前後の状態を行き来きできるようにする
    ・取り入れた技術として
    　→ Github Actions Workflow
    　→ git のブランチの仕組み、git submodule
    　→ Pull Request
    

    View Slide

23. 今後の課題
    ・総コード量 500 行程度（想定より大きい）
    ・DB のスキーマ操作を伴うメンテは、コピペになってしまう
    ・一回の Run に時間がかかる（２ 〜 ５分程度）
    

    View Slide

24. View Slide