実際にリリースするための手段を知ろう / release-safely-2

実際にリリースするための手段を知ろう～当たり前にリリースしていくために必要なこと～ Classi社様新卒研修第2回そーだい塾

前回      What is it?

サービスを壊さずにリリースする～当たり前にリリースしていくために必要なこと～ Classi社様新卒研修第1回そーだい塾

価値を提供するために    リリースを行う  What is it?

リリースを継続的に行う      What is it?

リリースを継続的に行う  ↓  価値を提供し続ける  What is it?

しかし、リリースは常に    変化を提供する  What is it?

変化は時に驚きと問題を連れてくる      What is it?

そのために必要な実践的な話      What is it?

1. 自己紹介  2. 小さく、素早く、始める  3. データベースを生かしたまま動かす  4. ログとリトライとリラン  5. まとめ 
あじぇんだ

自己紹介  曽根壮大（36歳）  Have Fun Tech LLC 代表社員    そ　
ね　　たけとも  • 日本PostgreSQLユーザ会勉強会分科会担当  • 3人の子供がいます（長女、次女、長男）  • 技術的にはWeb/LL言語/RDBMSが好きです  • コミュニティが好き

あじぇんだ

スコープは小さく    リリースは素早く  小さく、素早く、始める

Small is beautiful.    小さいものは美しい  小さく、素早く、始める

Small is beautiful. 小さなプログラムという発想 1. 小さなプログラムはわかりやすい 2. 小さなプログラムは保守しやすい 3. 小さなプログラムはシステム
リソースに優しい 4. 小さなプログラムは他のツールと組み合わせやすい https://amzn.to/33QPAdv

Make each program do one thing well.    1つのプログラムには  1つのことをうまくやらせる 
小さく、素早く、始める

Make each program do one thing well. 一つのことに集中することでプログラムに不要な部分をなくせる。不要な部分があると、
実行速度が遅くなり、不必要に複雑になり、融通が効かない。 https://amzn.to/33QPAdv

Build a prototype as soon as possible.    できるだけ早く試作する  小さく、素早く、始める

Build a prototype as soon as possible. ソフトウェアには常に改善の余地はあるのはもちろんだし、時間的な制約などでそのソースコードは必ずしも最高の状態が保た
れているわけではない。ほとんどのソフトウェアは妥協の産物だ。完成することはなく、ただリリースがあるだけだ。 https://amzn.to/33QPAdv

Build a prototype as soon as possible. UNIXの考え方では、なるべくはやく第三のシステムを構築するために、すばやく試作することをおすすめしている。
直接、第三のシステムをつくることはできないのだ。 1. 短い機能仕様書を書く (3〜4枚程度) 2. ソフトウェアを書く 3. テストして書き直す。満足できるまで、これを繰り返す。 4. 詳細なドキュメントを (必要なら)書く https://amzn.to/33QPAdv

Unixの哲学を    どうやって実現するか  小さく、素早く、始める

小さくリリースする      小さく、素早く、始める

小さくリリースする  ↓  例えば、段階的リリース  小さく、素早く、始める

<?php $view_flag = $_GET[‘v’]; ?> <html> <head> <title>サンプル</title> </head> <body>
<p>PHPのテストです。</p> <?= $view_flag ? $view : null ?> </body> </html> https://hoge.com?v=true 特定のフラグのときだけ、特定の表示する 1. ボタン 2. リンク 3. バナー 4. コンポーネント 5. 画面 6. 機能 Viewを見せない

全てを同時にリリースしない      小さく、素早く、始める

全てを同時にリリースしない  ↓  影響範囲を分割する  小さく、素早く、始める

影響範囲を分割する  • データベースの変更だけ行う  ◦ テーブル・カラム追加とコードのリリースを分ける  • CSSやJSなどの静的ファイルを先にリリースする  • フロントとバックエンドのリリースを分ける ...etc 

影響範囲を分割する  • ALBでリリース対象をロードバランシングする  • DNSで切り替える  ◦ pre.host.name → prod.host.name  •
参照するデータを分ける  小さく、素早く、始める

スコープは小さく    新たな複雑を導入しない  小さく、素早く、始める

シンプルと    イージーは違う  小さく、素早く、始める

常にロールバックを出来る      小さく、素早く、始める

あじぇんだ

小さくリリースするためには    データベースが鬼門  データベースを生かしたまま動かす

データベースは状態を持つ  • UPDATEやDELETEは破壊的変更  • テーブル変更やカラム変更も破壊的変更  ◦ データが変わると元には戻しにくい  ◦ ロールバックしずらい  データベースを生かしたまま動かす

状態が変更されると    元に戻せないから難しい  データベースを生かしたまま動かす

データベースから状態を排除する      データベースを生かしたまま動かす

データベースから状態を排除する  ↓  それは設計の役目  データベースを生かしたまま動かす

https://soudai.hatenablog.com/entry/2018/05/01/204442 データベースを生かしたまま動かす

リリースする時、データベースの変更は    先にリリースできないか考えること  データベースを生かしたまま動かす

ADDで対応する      データベースを生かしたまま動かす

ADDで対応する  • INSERTとDELETEだけで設計する  • テーブルやカラムもADD  • flagやstatusを追加したくなったとき、  そのテーブルの責務が大きすぎないか考えること  データベースを生かしたまま動かす

データベースの責務を考えるタイミング  • 一つのテーブルに5つ目のINDEXを設定する時  • テーブルにUPDATEを手動で実行したい  • 一つのテーブルで複数の意味を持つことに気付いた  • 実行したい集計SQLが難しい  データベースを生かしたまま動かす

そーだい本 

どこまで行くと    元に戻せないリリースになるのか  データベースを生かしたまま動かすつまりここがバックアップが必要になるポイント！

事前に切り戻す条件を    決めておくこと  データベースを生かしたまま動かす

ロールバック出来ない時にどうするか  • 転ばぬ先の杖のバックアップ  ◦ 戻すのにどれくらい時間がかかるかもセット  • 覚悟を決めて突き進む  ◦ バグが出たら戦うしか無い  ◦
影響範囲を小さく→深夜リリースの機運  データベースを生かしたまま動かす

データベースが複数ある時    この問題が掛け算で発生する  データベースを生かしたまま動かす

データストアは最後の最後まで    最小限の数に抑えるべき  データベースを生かしたまま動かすシャーディングはやらなくていいならやらない

あじぇんだ

今からエンジニア人生で    とても大事なことを伝えます  ログとリトライとリラン

とにかくログを正しく残せっ！！      ログとリトライとリラン

とにかくログを正しく残せっ！！  ↓  そして再利用できる仕組みを用意する  ログとリトライとリラン

再利用できる仕組み      ログとリトライとリラン

再利用できる仕組み  ↓  リトライとリラン  ログとリトライとリラン

ログとリトライとリラン

最初から失敗を許容する      ログとリトライとリラン

失敗を許容する  • ログを元に再実行できる  ◦ 冪等性  • ログを元にデータを再現できる  ◦ 再現性  •
ログを元にどこまで・何が・どうなったかわかる  ◦ 可観測性  ログとリトライとリラン

Batchは冪等にすること      ログとリトライとリラン

外部APIのリクエストやコネクションは    失敗したらリトライする  ログとリトライとリラン

ロングトランザクションは    トレースできること  ログとリトライとリラン例えば状態変更の履歴とか

ログとリトライとリランができれば    多くの問題は解決する  ログとリトライとリラン

それを実現するためには    シンプルなシステムであることが重要  ログとリトライとリラン

あじぇんだ

事故を未然に防げる仕組み    事故から復旧できる仕組み  まとめ

失敗を最初から考慮する      まとめ

失敗を最初から考慮する  ↓  ロールバック、リトライ、リラン  まとめ

どうしても破壊的な変更が必要なら    その決断は本当に必要か考える  まとめいい方法が思い浮かばないときは時期早々（技術的な観点では）

“科学の成果をどういう風に役立たせるか、これが技術ですね。  科学の価値は、どれほど新しい知識か、という点で評価されます。  (中略)  自然界のルールを解明する体系的な知識が科学であり、それを社会や  企業の利益、医療の向上のため活用するノウハウが技術です。”  https://www.shinryo.com/special/contents01_3.html   ノーベル物理学賞江崎玲於奈 
まとめ

科学を活用して    問題を解決する力  まとめ

科学（ソフトウェア）を活用して    問題を解決する力  まとめ

ソフトウェアを活用して    問題を解決するのが    ソフトウェアエンジニア  まとめ

ソフトウェアが解決する問題の    価値のサイズが我々の価値  まとめ

価値を提供するために    リリースをしよう！  まとめ

手を動かしたものだけが世界を変える    -- id:onishi  まとめ

ご清聴ありがとうございました      まとめ

実際にリリースするための手段を知ろう / release-safely-2

実際にリリースするための手段を知ろう / release-safely-2

More Decks by soudai sone

Other Decks in Technology

Featured

Transcript