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

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

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

# 前回:当たり前にリリースしていくために必要なこと / Release safely
https://speakerdeck.com/soudai/release-safely

# UNIXという考え方
https://amzn.to/33QPAdv

# 第1回 江崎玲於奈氏 (ノーベル賞物理学者) に聞く “企業における創造性”
https://www.shinryo.com/special/contents01_3.html

# ユーザ情報を保存する時のテーブル設計
https://soudai.hatenablog.com/entry/2018/05/01/204442

88f4e84b94fe07cddbd9e6479d689192?s=128

soudai sone

May 17, 2021
Tweet

Transcript

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

  2. 前回
 
 
 What is it?

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

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

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

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

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

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

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

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


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


    あじぇんだ
  12. 自己紹介
 曽根 壮大(36歳)
 Have Fun Tech LLC 代表社員
 
 そ 

    ね   たけ とも
 • 日本PostgreSQLユーザ会 勉強会分科会 担当
 • 3人の子供がいます(長女、次女、長男)
 • 技術的にはWeb/LL言語/RDBMSが好きです
 • コミュニティが好き
  13. 1. 自己紹介
 2. 小さく、素早く、始める
 3. データベースを生かしたまま動かす
 4. ログとリトライとリラン
 5. まとめ


    あじぇんだ
  14. スコープは小さく
 
 リリースは素早く
 小さく、素早く、始める

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

  16. Small is beautiful. 小さなプログラムという発想 1. 小さなプログラムはわかりやすい 2. 小さなプログラムは保守しやすい 3. 小さなプログラムはシステム

    リソースに優しい 4. 小さなプログラムは他のツールと組 み合わせやすい https://amzn.to/33QPAdv
  17. Make each program do one thing well.
 
 1つのプログラムには
 1つのことをうまくやらせる


    小さく、素早く、始める
  18. Make each program do one thing well. 一つのことに集中することで プログラムに不要な部分をなくせる。 不要な部分があると、

    実行速度が遅くなり、 不必要に複雑になり、 融通が効かない。 https://amzn.to/33QPAdv
  19. Build a prototype as soon as possible.
 
 できるだけ早く試作する
 小さく、素早く、始める

  20. Build a prototype as soon as possible. ソフトウェアには常に改善の余地はあるの はもちろんだし、時間的な制約などでその ソースコードは必ずしも最高の状態が保た

    れているわけではない。 ほとんどのソフトウェアは妥協の産物だ。 完成することはなく、ただリリースがあるだ けだ。 https://amzn.to/33QPAdv
  21. Build a prototype as soon as possible. UNIXの考え方では、なるべくはやく第三のシス テムを構築するために、すばやく試作 することをおすすめしている。

    直接、第三のシステムをつくることは できないのだ。 1. 短い機能仕様書を書く (3〜4枚程度) 2. ソフトウェアを書く 3. テストして書き直す。 満足できるまで、これを繰り返す。 4. 詳細なドキュメントを (必要なら)書く https://amzn.to/33QPAdv
  22. Unixの哲学を
 
 どうやって実現するか
 小さく、素早く、始める

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

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

  25. <?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を見せない
  26. 全てを同時にリリースしない
 
 
 小さく、素早く、始める

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

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


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

    参照するデータを分ける
 小さく、素早く、始める
  30. スコープは小さく
 
 新たな複雑を導入しない
 小さく、素早く、始める

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

  32. 小さく、素早く、始める

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

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


    あじぇんだ
  35. 小さくリリースするためには
 
 データベースが鬼門
 データベースを生かしたまま動かす

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

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

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

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

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

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

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

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

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

  45. そーだい本


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

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

  48. ロールバック出来ない時にどうするか
 • 転ばぬ先の杖のバックアップ
 ◦ 戻すのにどれくらい時間がかかるかもセット
 • 覚悟を決めて突き進む
 ◦ バグが出たら戦うしか無い
 ◦

    影響範囲を小さく→深夜リリースの機運
 データベースを生かしたまま動かす
  49. データベースが複数ある時
 
 この問題が掛け算で発生する
 データベースを生かしたまま動かす

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

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


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

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

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

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

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

  57. ログとリトライとリラン

  58. ログとリトライとリラン

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

  60. 失敗を許容する
 • ログを元に再実行できる
 ◦ 冪等性
 • ログを元にデータを再現できる
 ◦ 再現性
 •

    ログを元にどこまで・何が・どうなったかわかる
 ◦ 可観測性
 ログとリトライとリラン
  61. Batchは冪等にすること
 
 
 ログとリトライとリラン

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

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

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

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

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


    あじぇんだ
  67. 事故を未然に防げる仕組み
 
 事故から復旧できる仕組み
 まとめ

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

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

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

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


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

  73. 科学(ソフトウェア)を活用して
 
 問題を解決する力
 まとめ

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

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

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

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

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