DevOps with Database on AWS

Amazon Web Services Japan

More Related Content

1.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.DevOps with Database on AWSアマゾン ウェブ サービス ジャパン株式会社 技術統括本部2018年11月1日
2.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.自己紹介山内 晃 （やまうち あきら）アマゾン ウェブ サービス ジャパン株式会社ストラテジックアカウント本部ソリューションアーキテクト好きなAWSサービス• Amazon Relational Database Service (RDS)• Amazon Simple Storage Service (S3)
3.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.このセッションについてこんな方にオススメです• 開発サイクルの短縮や開発プロセスへの集中といった効果を狙ってDevOpsに取り組まれているアプリケーション開発者• 従来どおりの安定運用に加えて変化への対応スピードが求められているデータベース管理者こんなことをお話しします• DevOps with Database はなぜ難しいのか？• “銀の弾丸がない” この課題にアプリケーション、データベースの観点からどうアプローチできるか？
4.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.Agenda• 前半（山内）• DevOps with Database はなぜ難しいのか• スキーマ変更にかかる時間を短縮するには• 後半（大村）• スキーマ変更のバージョンを適切に管理するには• 停止時間を最小化するリリース方法の例
5.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.DevOpsとはDevOps =開発者 顧客releasetestbuildplan monitorデリバリのパイプラインフィードバックループ無駄やボトルネックを取り除くことで、ライフサイクルを効率化し、高速化することソフトウェア開発のライフサイクル
6.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.DevOps with Database はなぜ難しいのか
7.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.変更対象 が異なるアプリケーションソースコード スキーマ定義とデータデータベース
8.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.所要時間 が異なるアプリケーション秒 〜 分 秒〜日（操作やサイズ等に依存）データベース
9.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.担当者 が異なるアプリケーションDeveloper DBAデータベースpublic class HelloWorld{public static void main(String[] args){System.out.println("Hello World!!");}}CREATE TABLE t1 (year_col INT,some_data INT)PARTITION BY RANGE (year_col) (PARTITION p0 VALUES LESS THAN (2017),PARTITION p1 VALUES LESS THAN (2018),PARTITION p2 VALUES LESS THAN MAXVALUE);
10.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.変更管理 が異なるアプリケーションバージョン管理ツール プロジェクト独自データベース
11.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.DevOps with Database はなぜ難しい？1. スキーマ変更に時間がかかる2. バージョン管理が難しい3. スキーマ変更はアプリケーションの停止を伴う
12.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.DevOps with Database を実現するには？1. スキーマ変更に時間がかかる→ 短時間でスキーマを変更するには？2. バージョン管理が難しい→ 安全にバージョン管理するには？3. スキーマ変更はアプリケーションの停止を伴う→ リリース方法を工夫して停止時間を短縮するには？この3つの課題にフォーカスして考えてみましょう
13.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.スキーマ変更にかかる時間を短縮するには
14.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.データベースのスキーマ変更とは• テーブル の作成、削除、名前変更、最適化、圧縮、文字コード指定• カラム の追加、削除、名前変更、並び替え、データ型変更• キー（プライマリキー、外部キー）の追加、削除、削除＆追加• インデックス の追加、削除、名前変更、タイプ変更• パーティション の作成、追加、削除• ビュー の作成、変更、削除etc...データ定義言語（DDL）によるオブジェクト定義の変更
15.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.スキーマ変更のパターン• メタデータだけを変更するDDLカラム名変更、インデックス削除、ビュー作成 など• 既存データのコピーを伴うDDLカラム追加・削除、インデックス追加、プライマリキー追加 など→ 通常、瞬時に終了するのであまり気にすることはない→ データ量に依存して時間がかかる（アプリケーションへの影響が懸念）
16.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.既存データのコピーを伴うDDL② 新しい定義で空の一時表を作る③ 元テーブルのデータをコピーTBL④ リネームしてテーブルを入れ替え① 元テーブルをロック（参照は許可、更新はブロック）更新 ×参照 ○参照 ○⑤ ブロックしていた更新をリダイレクトして反映更新TBL（例）MySQL5.7でのカラム追加
17.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.スキーマ変更を手堅くやるには• アプリケーション（更新もしくは全体）を停止• スナップショットを取得• DDLを実行• （問題が発生したらスナップショットから復旧）• アプリケーションを再開→ この方法だとDevOpsパイプラインに含めることは困難（実行時間やアプリケーション影響が読めず自動化しづらい）→ オンラインで（更新をブロックせずに）スキーマ変更したい
18.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.オンラインでのスキーマ変更（MySQL）• オンラインDDL（MySQL 5.6以降）DDLの例（MySQL 5.7） テーブル再構築 同時DML• テーブル名変更、カラム名変更• 外部キー制約追加、削除• インデックス削除不要 可能• カラム追加、削除、並び替え• プライマリキー追加、削除＆追加• インデックス追加（*1）必要 可能• カラムデータ型変更• プライマリキー削除• パーティション作成、追加、削除 (*2)必要 不可*1 再構築ではないが、データ量依存で時間がかかる*2 パーティションのタイプや操作に依存（例：レンジ、リストのパーティション追加、削除はコピー不要など）ALTER TABLE item ADD COLUMN price INT, ALGORITHM=INPLACE, LOCK=NONE;
19.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.オンラインでのスキーマ変更（Oracle Database）• オンライン・データ再定義（Enterprise Edition）• DBMS_REDEFINITIONパッケージを利用• スキーマ変更中にDMLを実行できる• カラムの追加、削除、名前変更、表領域の移動、圧縮属性の変更など様々な操作に対応• カラム追加時のデフォルト値の最適化• 既存レコードがすべて更新される（10gR2以前）• デフォルト値をメタデータだけに格納• NOT NULL制約が必要（11g）/ 不要（12c）-- 元テーブル（original）を作成CREATE TABLE original (col1 NUMBER PRIMARY KEY,col2 VARCHAR2(100)) TABLESPACE users;-- 仮テーブル（interim）を作成CREATE TABLE interim (col1 NUMBER PRIMARY KEY,col2 VARCHAR2(100), col3 VARCHAR2(100))TABLESPACE users;-- オンライン再定義を開始BEGINDBMS_REDEFINITION.START_REDEF_TABLE(uname => 'master',orig_table => 'original',int_table => 'interim',col_mapping => 'col1 col1, col2 col2',options_flag =>DBMS_REDEFINITION.CONS_USE_PK);END;/-- オンライン再定義を終了execDBMS_REDEFINITION.FINISH_REDEF_TABLE('master','original','interim');【実行例】テーブル（original）にカラム（col3）を追加
20.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.オンラインでのスキーマ変更（SQL Server）• ONLINE ALTER COLUMN（Enterprise Edition）• SQL Server 2016以降のTransact-SQLでオンラインでの列変更をサポート• 制限事項についてはドキュメントで要確認 (*)• 複数列を同時に変更することはできない• チェック制約で参照されている列は変更できない• 変更される既存の列には2倍の領域割り当てが必要 etc..* ALTER TABLE (Transact-SQL)https://docs.microsoft.com/ja-jp/sql/t-sql/statements/alter-table-transact-sqlALTER TABLE item ADD price INT WITH (ONLINE = ON);
21.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.新テーブルにカラム追加して結合する参照参照参照③ 参照はビューを見せるTBL ① 追加カラムを持つ新テーブルを作成TBL_1 TBL_N・・・② 新旧テーブルを結合してビューを作成（変更）VIEW更新④ 更新はテーブルに行うHow?• カラム追加をテーブル作成とビュー作成（変更）に置き換えるPROS CONS• 停止時間を短縮できる（更新を長時間ブロックしない）• キー値のコピーが必要（テーブル作成時）• 結合ビューは複数テーブルを更新できない• 繰り返すと結合が多くなる
22.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.予備カラムを定義するtitle pages更新参照参照③ 参照、更新共にビュー経由で行うyobi1 yobi2② ビューを作成（変更）し、カラム名を変更VIEW① 予備カラムを定義してテーブルを作成TBLHow?• カラム追加をビュー変更で置き換えるPROS CONS• 停止時間を短縮できる（更新を長時間ブロックしない）• 必要数分の予備カラムを予め定義• データ型、キー、制約、インデックスの変更には対応できない（ALTER TABLEが必要）
23.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.JSON型を使う-- JSON型のカラムを定義してテーブル作成CREATE TABLE item (id INT, name VARCHAR(20), tags JSON);-- 異なる属性を持つJSON型のデータを挿入INSERT INTO item (id, name, tags) VALUES (1, 'Book', JSON_OBJECT(‘title', ‘The Four', 'pages', '245'));INSERT INTO item (id, name, tags) VALUES (2, 'PC', JSON_OBJECT(‘type’, ‘laptop', 'weight', '1.37'));-- 属性を指定してJSON型のデータを検索SELECT id, name FROM item WHERE JSON_EXTRACT(tags, "$.weight") = "1.37";How?• JSON型のカラムを定義して、単一のカラムで属性が異なる複数の値を格納するPROS CONS• RDBMSの特性を残したまま、NoSQLの柔軟性（スキーマレス）を使える• 検索が遅い（インデックスが使えない）• 検索や更新の実装が複雑になる• 値の妥当性検証（データ型）や参照整合性（外部キー制約）の担保が困難になる
24.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.前半のまとめ（DevOps with Database を実現するには？）1. スキーマ変更に時間がかかる→ 短時間でスキーマを変更するには？• オンラインでのスキーマ変更• 新テーブルにカラム追加して結合する• 予備カラムを定義する• JSON型を使う2. バージョン管理が難しい→ 安全にバージョン管理するには？3. スキーマ変更はアプリケーションの停止を伴う→ リリース方法を工夫して停止時間を短縮するには？
25.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.自己紹介大村 幸敬 （おおむら ゆきたか）アマゾン ウェブ サービス ジャパン株式会社インダストリソリューション部ソリューションアーキテクト好きなAWSサービス• AWS CLI (Command Line Interface)
26.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.Evolutionally Database Designアジャイル開発でデータベースの Continuous Integration とリファクタリングを行うための 11のプラクティスを紹介https://www.martinfowler.com/articles/evodb.htmlby Martin Fowler & Pramod Sadalage (2016)1. DBAとデベロッパがコラボレートする2. DB成果物をアプリとともにバージョン管理する3. 全てのDB変更はマイグレーションで管理する4. 全ての開発者に自分のDBを提供する5. 開発者はDBの変更を継続的に統合する6. DBはスキーマとデータで構成される7. 全てのDBの変更はリファクタリングである• DBの移行中フェーズの扱い8. リファクタリングを自動化する9. 開発者が自分のDBをOnDemandで更新できる10. DBへのアクセスコードを明確に分離する11. 頻繁にリリースする
27.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.DevOps with Database を実現するには？1. スキーマ変更に時間がかかる→ 短時間でスキーマを変更するには？2. バージョン管理が難しい→ 安全にバージョン管理するには？3. スキーマ変更はアプリケーションの停止を伴う→ リリース方法を工夫して停止時間を短縮するには？
28.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.スキーマ変更のバージョンを適切に管理するには
29.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.アプリ開発に伴うDBの変更スキーマ定義(DDL)マスタデータ変更後データ(DML)
30.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.DBの変更作業DBへの変更要求をコード変更に合わせて適用するには？コード DB変更要求開発者Production DBコード DB変更要求Integration DBDBAStaging DBDev DB開発者v1 v1v2 v2
31.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.全てのDB変更をマイグレーションで管理• ツールによるマイグレーションの管理と自動化• スキーマの変更をDDL/DMLのセットで定義• 適用時およびロールバック時の処理をコードで記述IntegrationDBStagingDBProductionDBDBAv1 v2v3v4v5v6v7Dev DBDev DBDev DBDev DBv7 v6 v5
32.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.マイグレーションの実装例Ruby on Rails の Active Records• マイグレーションファイル• DBスキーマをDSLで定義• ver up/down時の処理を記述• 任意のSQL記述も可能• マイグレーションファイル構成• db/migrate ディレクトリに配置• ファイル名形式はYYYYMMDDHHMMSS_add_products.rb
33.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.マイグレーションの実行例指定したバージョンのマイグレーションまでを実行ロールバックしてひとつ前のバージョンに戻る$ rails db:setup$ rails db:rollback$ rails db:migrate VERSION=20181101120000DBの初期化特定バージョンのマイグレーション処理のみを実行$ rails db:migrate:up VERSION=20181101120000異なる環境のマイグレーションを実行$ rails db:migrate RAILS_ENV=devv0v2v5ProductionDevv1v2v3v4v5v5v5
34.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.さまざまなDBマイグレーションツールフレームワークに付属• Ruby on Rails (Ruby)• Laravel (PHP)• Entity Framework (.NET)• Django (Python)• etc...専用ツール• Flyway• Liquibase• MyBatis• Phinx• sql-migrate• etc...
35.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.DevOps with Database を実現するには？1. スキーマ変更に時間がかかる→ 短時間でスキーマを変更するには？2. バージョン管理が難しい→ 安全にバージョン管理するには？3. スキーマ変更はアプリケーションの停止を伴う→ リリース方法を工夫して停止時間を短縮するには？
36.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.停止時間を最小化するリリース方法の例
37.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.DevOpsと無停止リリース• 外部調停なくリリースできることはDevOpsに必須• リリースに伴う停止時間がなければ外部調停不要• 無停止リリースの課題： 移行フェーズ• アプリ変更、DBスキーマ変更に伴う停止時間• 新旧アプリと新旧スキーマの組み合わせのハンドリングDatabase refactorings, being applied to legacy database and the phases it needs to take before being implemented from Evolutionally Database Design
38.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.リリースへの影響：ステートレスとステートフル• ステートレスなアプリケーションの変更• 複数のサーバやコンテナ• 順に停止&起動することで無停止入れ替え可能• ステートフルなデータストアの変更• 多くは単一のデータストアを共有• 単純に更新すると停止時間が発生• 構造化データストアはスキーマ変更が課題• 非構造化データストアはスキーマ変更不要v1 v1v1v2v2StatelessStateful
39.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.無停止リリースのパターン A: DBを共有DBとアプリの変更を個別に実施• DBとアプリケーションが疎結合であること• 新旧アプリでDBを共有• 一般的にはこの方法を推奨リリースのパターン1. DBスキーマ変更→アプリ変更2. アプリ変更→DBスキーマ変更ChangeschemaStart appdeploymentFinish appdeploymentStart appdeploymentFinish appdeploymentChangeschema
40.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.パターンA-1: DBスキーマ変更を先行旧アプリが新スキーマで稼働できる場合 （カラム追加など）• 例）新アプリで不要なカラムが残る可能性があるが無視• 例）旧アプリが追加したデータをTriggerで新スキーマへ投入v1 v1 v1v1v1 v1 v1v2v2 v2 v1v2v2 v2 v2v2• 旧アプリ• 新スキーマ• 新旧アプリ混在• 新スキーマスキーマ変更に伴う処理停止の最小化アプリデプロイに伴う処理停止の最小化(Draining)移行フェーズ
41.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.パターンA-2: アプリリリースを先行新アプリが旧スキーマで稼働できる場合（カラム削除など）• 例）リリース完了後は旧アプリを稼働できない• 例）削除されたカラムへの依存が新アプリに残っているとエラーが発生（要テスト）v1 v1 v1v1v2 v2 v1 v2 v2 v2v2• 新旧アプリ混在• 旧スキーマ• 新アプリ• 旧スキーマスキーマ変更に伴う処理停止の最小化アプリデプロイに伴う処理停止の最小化(Draining)v1 v1v2 v2 v2移行フェーズ
42.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.閑話休題：アプリバージョンの混在新機能はいつから有効か？• デプロイされ次第• フィーチャーフラグが変更され次第フィーチャーフラグはどこに配置するか？1. アプリサーバ上のファイル• CodeDeploy や SSM* RunCommandで設定2. 設定格納用のデータストア• SSM* ParameterStoreに格納3. データと同じDB• マイグレーションで管理機能A: ◯機能B: ×SSM Parameter Store*SSM = AWS Systems ManagerSSM RunCommandDBv2 v2 v1
43.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.無停止リリースのパターン B: 異なるDBの使用DB自体を切り替える• 変更が大きくスキーマ変更処理やデータコピーによる停止が許容できない場合• アプリとDBが密結合で個別リリースできない場合課題：新旧DBのデータを一致させること• 基本的に難しい問題リリースのパターン1. 主系DBのデータをレプリケーション2. 新旧両方のDBをDouble Writeで更新
44.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.パターンB-1: レプリケーションPros: トランザクション管理の複雑さを回避可能（DBが管理）Cons:切替え時にデータ同期完了まで待つ必要があるRDBMSにより異スキーマ間のレプリ可否が異なるW R R W R W R事前にGreen環境のスキーマを変更新旧スキーマ間でレプリ書き込み停止レプリ完了待ち読み込みは可能アクセス先切り替え書き込み再開切り戻しに備えた逆レプリ（または別DBへのレプリ）移行フェーズ
45.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.パターンB-2: Double WritePros: DBによらずアプリケーションの制御で無停止切り替え、切り戻しが可能Cons: データ整合性をアプリケーションで管理する必要がある書き込み速度の低下（2-phase-commitの実施など）W R RWR W R両系DBに書き込み開始アクセス先切り替え切り替えの完了移行フェーズW新スキーマで準備
46.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.まとめ - DevOps with Database を実現するには？1. スキーマ変更に時間がかかる→ 短時間でスキーマを変更するには？2. バージョン管理が難しい→ 安全にバージョン管理するには？• DBマイグレーションツールの使用3. スキーマ変更はアプリケーションの停止を伴う→ リリース方法を工夫して停止時間を短縮するには？• 銀の弾丸はない• A: DBを共有: スキーマ変更とアプリ変更の組み合わせ• B: 異なるDBを使用: レプリケーションやDoubleWrite
47.© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.Thank you!