Upgrade to Pro — share decks privately, control downloads, hide ads and more …

プログラマ三大美徳を実現するデプロイフローを目指して

 プログラマ三大美徳を実現するデプロイフローを目指して

PHPerKaigi 2021 の発表で使ったスライドです。

Tomoya-Suzuki

March 28, 2021
Tweet

More Decks by Tomoya-Suzuki

Other Decks in Programming

Transcript

  1. プログラマの三大美徳 とは Wikipedia によれば 1. 怠惰(Laziness) 2. 短気(Impatence) 3. 傲慢(Hubis)

    • プログラマ三大美徳を唱え始めたのは Perl 開発者のラリー・ウォール • 効率や再利用性の重視・処理速度の追求・品質にかける自尊心
  2. リリース関係のステップ • PRマージ • release ブランチの作成 • 必要に応じて修正やリリースフラグ変更 • release

    タグの作成 • dev環境デプロイ • 本番デプロイ ◦ DB migrate ◦ memcached の cache clear ◦ その他最適化(view cache, route cache) ◦ Elasticsearch の index 更新
  3. 弊社で自動化されている部分 • PRマージ(approveされたら自動) • release ブランチの作成(コマンド一発、pushまで) • 必要に応じて修正やリリースフラグ変更(手動でPR) • release

    タグの作成(コマンド一発、pushまで) • dev環境デプロイ(pushされたら勝手にデプロイ) • 本番デプロイ ◦ circle CIからワンクリック ◦ DB migrate(自動) ◦ memcached の cache clear(自動) ◦ その他最適化(view cache, route cache) (自動) ◦ Elasticsearch の index 更新 (自動)
  4. 2018年8月 • 鈴木(私)が2人目エンジニアとして入社 • develop ブランチをそのままデプロイ ◦ eb deploy macloud-dev

    ◦ eb とは AWS ElasticBeanstalk というEC2やLB、オートスケールの管理などやってくれる • AWS ElasitcBeanstalkコンソールから本番に手動デプロイ • 検索サーバのindex更新は手動 • 環境設定は手動 • PMなし。デプロイはエンジニアがやりたい時にやる • DB migrate, cache clearは手動 ◦ 次ページで詳しく こ こ
  5. 「DB migrate, cache clearは手動」 の詳細 • (雑に)サーバ1台の場合のeb deploy の内部的ステップ 1.

    zipでS3にコードが上がる 2. コードがサーバ内に配置される 3. 即座にLB経由でアクセスがくる • 2のタイミングで急いで手動でコマンド ◦ php artisan migrate ◦ php artisan cache:clear • 実行遅れると ◦ DBの状態が古いのでコードと食い違いエラー • 詳細はこちら ◦ https://tech.macloud.jp/entry/2020/01/08/121733
  6. 2019年05月 • 津崎(@zackey2)さん入社。エンジニア3人目 • git flow を手動で運用開始 • しばらく運用定まらず、定式化されるまでマニュアル運用 導入目的

    • developブランチ からリリース(①) • 無関係な②をコミットしてから問題が発覚!! • 修正(③)を develop に入れてリリースせざるをえない • ②もしれっと本番デプロイされてしまう • hotfix を導入したい! こ こ
  7. 2019年11月 • 徐々に募集記事が増えてきて、検索体験を向上させたい • 初めてのElasticsearchの index の mapping(型情報)更新 • ダウンタイム無しで

    index 更新したい 方法 • APIエンドポイントを叩くと、新しい型情報で index を作成 • 定期更新バッチでは新旧二つの index を同時更新 • 手動で alias を切り替える • 更新頻度が低いのでとりあえず手動で運用開始
  8. 2019年12月 • ユーザ同時接続も増えてきた • CircleCI に migrate と cache clear

    の自動化を導入 🎉 • しかし思わぬトラブルが・・・
  9. トラブル • migrate & cache:clear しているはず • でも、WebサーバでDB古いような不整合のエラー 何が起こった? •

    リリース時にサーバー二台に対してデプロイ • キャッシュクリアは各サーバで行われる • リリース中のユーザアクセスで、古いサーバによりキャッシュが再作成 • 新しいサーバで参照してエラー
  10. 2020年03月 • 5人目エンジニアの濱田(@hamakou108)さん入社 • リリースタグ作成を手動から自動へ 🎉 • reletan script の導入

    やった理由 • リリース方法情報伝達が面倒 • エンジニア増えたのでミス増加の懸念 こ こ
  11. reletan script とは? • reletan とは? ◦ release tantou ◦

    リリース担当! • りりたん指名の風景 👇
  12. reletan script とは? • めんどくさいリリースブランチ作成とタグ作成を半自動化 • local repository を最新に •

    git flow コマンド自体の設定 • 前回タグからの差分PRリスト抽出 • ブランチ作成やタグ作成をリモートに自動反映
  13. 同 2020年08月 • 大きな機能のリリースが増えてきた • feature フラグを使用することで、フラグをオフにしてどんどんコードを本番に入れる • ※feature ブランチとして独自進化ブランチは

    やらない ◦ マージする時のコンフリクト解消つら過ぎ この手法の課題 • 環境変数はまだAWS ElasticBeanstalkのコンソールから管理していた (手動) • dev, prod で同じ値を設定するが、オペミスが発生しやすい 解決策 • 環境変数もコードで管理 🎉 • .env.visible と .env.secret を分離して運用負荷は重くならないように • CircleCIでデプロイ前に.envにまとめて巻き込むように
  14. 自動マージ仕組み • CircleCIで PRのURLは ${CIRCLE_PULL_REQUEST} • Github API の URLに変換

    • マージ可能状態 meageable_state を取得 • 判定OKなら Github API の merge エンドポイントを叩く ◦ 参考: https://docs.github.com/en/rest/reference/repos#merge-a-branch
  15. 2019年11月 workerサーバについて • before: メール送信のジョブ実行をWeb経由で実行 ◦ CloudWatch Event -> lambda

    -> Globalに露出しているElasticBeanstalkでジョブ受付 ◦ ジョブ処理を順次行うため、一斉メール送信などで処理がつまる = 他の通知が止まる ◦ ジョブ実行トリガーが Global(トリガだけなのでリスクは低いが、セキュリティ問題) • after: workerサーバを新設し、ジョブ処理をお任せ ◦ Webサーバからジョブを積み、 Workerで並列で処理 ◦ 処理がつまる問題の低減 ◦ 負荷も分散 Worker サーバが増えたがCircleCIでデプロイ自動化されているので安心
  16. 今後の課題 • worker と web が直列でデプロイされ、時間がかかる ◦ Webのコードが先にデプロイされると、古い Workerで実行され、コードが食い違うとエラーになる (多分)

    ◦ 対策案: ▪ ちょっとだけ時間差で workerが先に始まる ▪ IDを引き渡すだけのジョブにすることで問題を緩和 • デプロイフロー以外の確認や社内共有が手動が多い ◦ dev入った後のPMやそれぞれのエンジニアの確認 ◦ リリース後の、リリースリストを slack で共有