[B! デプロイ] akatakunのブックマーク

デプロイ / リリース手法まとめ

今回は「クラウドサービスへのデプロイ・リリース手法」についてまとめます。「ゼロダウンタイムデプロイ (Zero Downtime Deployment)」が言われるようになり、様々なデプロイ・リリース方法が出てきました。そこで今回はデプロイ/リリースの手法についていろいろと調べてまとめてみました。サイトによって「リリース」と「デプロイ」が混在して記述されている感じもありましたが…「デプロイ」の記載が多かったので今回は「デプロイ」で統一しました。なお、デプロイとリリースの違いについては「ビルド / デプロイ / リリース / ロールバックの意味や違い」にまとめているので参考にしてください。デプロイ/リリース方法を分類してみるクラウドサービスがあたりまえに使われるようになって種類が増えているため、ここでは「手法」「戦略」「対象」の3つの視点で分類してみました。分類方法は整

akatakun 2022/07/12

リンク

CrowdWorksデプロイ物語 - クラウドワークスエンジニアブログ

みなさんさようなら，最近デプロイが趣味の@h3_potetoです．この記事は，僕が趣味で改善していたCrowdWorksのデプロイ周りの大改造の歴史を振り返ります．基本的には，デプロイが趣味の方向けの記事です．とても長いです．手動構築の時代その昔，CrowdWorksのサーバは手動で構築されていました．手動でRuby等の設定をいれたサーバを複数台用意し，そこにcapistranoデプロイをしていました．インフラは手動構築だった割に，なぜかBlue/Greenデプロイを実現していました． Blue/Greenの実現方法まずはじめに， Blueが稼働系 Greenが待機系です． Blue/Greenデプロイをする際には，Green系にデプロイをして，Blue系と挿げ替え，旧Blue系をそのまま廃棄します．この動作をどこで実現しているかというと，なんとCrowdWorksのアプリ

akatakun 2019/08/07

アプリケーションデプロイとインフラデプロイをBlue/Green化したことで、影響範囲が広くなったり、時間がかかるようになったって話，アプリケーションデプロイはIn Placeで、インフラデプロイはBlue/Greenにして解決

リンク

AWS Solutions Architect ブログ

SA岩永です。クラウド時代になり、Blue/Greenデプロイと呼ばれる方式を取るシステムが増えてきました。ただ、日本語で書かれているBlue/Greenデプロイの情報は多少古いものが多いため、特にクラウドで真価を発揮するBlue/Greenデプロイについて2015年の最後に一度まとめてみたいと思います。以下は私の個人的な考えに基づくものであり、他にも様々な考え方があります。AWSのデプロイに関する発表でも沢山の考え方が提案されていますし、デプロイをサポートするサービスを多種多様に提供しています。1つの考え方として参考にして頂ければ幸いです。なおこの記事は、2015年のAWS re:Inventのセッション『(DVO401) Deep Dive into Blue/Green Deployments on AWS』を参考にしています。興味のある方はSlideshareやYoutubeを

akatakun 2019/08/07

[Blue/Green][良記事]

リンク

今さら聞けない Immutable Infrastructure - 昼メシ物語

Immutable （不変な） Infrastructure は、サーバを一度セットアップしたら二度と変更を加えないという運用スタイルのことを指します。クラウド環境では、必要に応じてすぐにサーバを用意し、不要になったら簡単に破棄することができます。Immutable Infrastructure は、このようなクラウドの特性を活かす運用スタイルとして、注目されつつあります。背景 Immutable Infrastructure が提唱された背景にある技術として、 Auto Scaling や Blue-Green Deployment*1 などがあります。 Auto Scaling Auto Scaling は、負荷に応じて自動的にサーバ台数を増減させる技術で、 AWS では標準で提供されています。常に必要な台数だけ起動していればいいので、コスト削減になるというものです。 Auto S

akatakun 2019/06/21

この制約を逆手に取り、「すべてのサーバは必ず使い捨てである」と割りきってしまえば、サーバの構築や管理がシンプルにできるのではないか、というのがImmutable Infrastructureの基本的な考え方です。

リンク

リトライと冪等性のデザインパターン - Blog by Sadayuki Furuhashi

リトライを肴に一晩酒が飲める古橋です。大規模なデータに触れることが日常茶飯事になっている今日この頃。この分野のおもしろいところは、いつまで経っても終わらないプログラムを簡単に作れてしまうことかもしれません。エラー処理、リトライそして冪等性*1の３つを抑えていないプログラムは、小規模なデータなら問題ないが、データ量が多くなると使い物にならなくなる可能性が大です。大規模データをバッチ処理するケース以外でも、リトライは一般にプログラムの信頼性に関わる重要な問題です。そんなわけで、リトライに関わるいくつかのデザインパターンを、連載でまとめておこうと思います*2。では、第1回は背景から：なぜリトライが必要なのかプログラムは色々な理由で失敗する。例えば、 A) 通信先のプログラムが高負荷すぎて応答できなかった B) メモリを消費しすぎてメモリ確保に失敗した。またはOOM KIllerに殺さ