自己紹介正野裕大マサノユウタ SRA OSS, Inc. 日本支社 OSS技術グループ主にAmazon Web Services (AWS) 関連のR&D活動に従事 SRA OSS, Inc. 日本支社 1999年よりPostgreSQLサポートを中心にOSSビジネスを開始 Postgre

Size: px

Start display at page:

Download "自己紹介正野裕大マサノユウタ SRA OSS, Inc. 日本支社 OSS技術グループ主にAmazon Web Services (AWS) 関連のR&D活動に従事 SRA OSS, Inc. 日本支社 1999年よりPostgreSQLサポートを中心にOSSビジネスを開始 Postgre"

みりあままだ
5 years ago
Views:

1 AWS上のPostgreSQL+で高可用性 / 負荷分散システムを目指す 2014年11月8日土新潟オープンソースセミナー2014 SRA OSS, Inc. 日本支社 OSS技術グループ正野裕大 1

2 自己紹介正野裕大マサノユウタ SRA OSS, Inc. 日本支社 OSS技術グループ主にAmazon Web Services (AWS) 関連のR&D活動に従事 SRA OSS, Inc. 日本支社 1999年よりPostgreSQLサポートを中心にOSSビジネスを開始 PostgreSQLなどのOSSサポート PostgreSQLをベースとしたPowerGresファミリの開発販売トレーニング導入設計コンサルティング 2

3 本日お話する内容 Amazon Web Services (AWS) 上でを使って PostgreSQLのHA構成組みました特に難しい話は出てこずベーシックな内容と導入事例のご紹介 1. HA構成とは 2. とは 3. Amazon Web Servicesとは 4. AWS上での+PostgreSQLの導入事例 3

4 本日お話する内容 Amazon Web Services (AWS) 上でを使って PostgreSQLのHA構成組みました特に難しい話は出てこずベーシックな内容と導入事例のご紹介 1. HA構成とは 2. とは 3. Amazon Web Servicesとは 4. AWS上での+PostgreSQLの導入事例 4

5 高可用性 (High Availability) とはサービスを停止しないで提供し続けられる能力のことサービス開始サーバを停止してバックアップ障害発生障害検知対処開始障害復旧完了の割合 = 稼働率ミッションクリティカル領域では可能な限りサービスのダウンタイムを短くしたい障害の発生確率を下げる構成要素の信頼性を上げるよりも冗長化メンテナンスの停止時間を短くする障害検知から復旧するまでの時間を短くする 5

6 稼働率目標と実現方法稼働率を高めたいならHA構成は必須稼働率年間停止時間 99% 3日15時間36分実現方法バックアップとリストア 99.9% 8時間46分バックアップとリストア + 夜間待機 99.99% 52分34秒 HA構成 + 手動切り替え + 夜間待機 % 5分15秒 HA構成 + 自動切り替え９９９９９９ 32秒特殊なハードウェア 6

7 PostgreSQLのHA構成稼働率 ~ 99% 予備機とバックアップリストアによる運用リカバリ時にデータ損失の可能性ありリストアの所要時間に合わせてベースバックアップの頻度は変える稼働サーバを監視障害を検知したら担当者に通知監視サーバ障害検知対応時間に合わせて担当者体制を作成する DB稼働サーバ予備機 PostgreSQL PostgreSQL PITRを使った定期的なベースバックアップの取得恒常的なWALのアーカイブ 7

8 PostgreSQLのHA構成稼働率 ~ % とHAクラスタリングソフトウェアの組み合わせ Pacemaker DBクライアントアクセスリソース管理仮想IP DB稼働系サーバ DB待機系サーバ PostgreSQL PostgreSQL HAクラスタソフト死活監視 HAクラスタソフト PostgreSQLのでデータ同期 8

9 本日お話する内容 Amazon Web Services (AWS) 上でを使って PostgreSQLのHA構成組みました特に難しい話は出てこずベーシックな内容と導入事例のご紹介 1. HA構成とは 2. とは 3. Amazon Web Servicesとは 4. AWS上での+PostgreSQLの導入事例 9

10 とは PostgreSQL専用のクラスタ管理ツール BSDライセンスのオープンソースソフトウェア pgpool Global development Group が開発 [pgpool Wiki] 多彩な機能コネクションプーリング参照負荷分散オンメモリクエリキャッシュ自動フェイルオーバーオンラインリカバリレプリケーション watchdog 10

11 の特徴クライアントとPostgreSQLの間で動作して様々な機能を提供 WebサーバにおけるプロキシサーバのようなものクライアントとPostgreSQLを透過的に繋いでクエリを中継既存のシステムになるべくそのまま導入できるように設計されているクライアントからは PostgreSQLに接続しているように見える PostgreSQLクライアント 11

12 のコネクションプーリングクライアントのDB接続オーバーヘッドを抑制するは PostgreSQL間のDB接続を保持クライアントがに接続時に上記の接続を再利用直接PostgreSQLに接続するよりオーバヘッドが小さくなる PostgreSQLクライアント接続コネクションを再利用接続切断 12

13 の参照負荷分散参照系クエリの振り分け先はクライアントのクエリを自動的に振り分けて負荷を低減各DBサーバに対する重み付けで相対的に決められる更新系クエリは稼動系PostgreSQLに参照系クエリはいずれかのPostgreSQLに 1 : 2 : 2 更新が重いシステムでは稼動系PostgreSQLに検索を投げずに負荷軽減 PostgreSQLの数だけスケールアウト可能検索検索 / 更新 PostgreSQLクライアント検索検索更新 13

14 の参照負荷分散新バージョンの 3.4.0が昨日 ( Fri) リリースされました 14

15 の参照負荷分散新バージョンの 3.4.0ではきめ細かい参照負荷分散が可能にアプリケーション名 DB名によって接続先を指定できる分析用の重い参照系クエリを分析専用PostgreSQLに送信サービスに影響を与えなくする重い検索検索分析アプリ検索 / 更新検索 Webアプリ PostgreSQLクライアント重い検索更新 15

16 の自動フェイルオーバ障害の発生したPostgreSQLを検知してHA構成から切り離し / 待機系昇格稼動系ダウン待機系PostgreSQLが自動的に稼動系に昇格待機系ダウン HA構成から切り離しヘルスチェックでPostgreSQLを監視応答なし切り離し / フェイルオーバ待機系サーバが昇格する HA構成から切り離す 16

17 のオンラインリカバリ稼働系PostgreSQLを利用してダウンした待機系PostgreSQLを作成ダウンした待機系を復旧させる新しい待機系を作成する稼動系PostgreSQLを停止させる必要はない参照性能のスケールアウトが簡単にできる 17

18 のwatchdog 自体の可用性を高める機能が単一障害点がダウンしたらサービス停止 PostgreSQLクライアント 18

19 のwatchdog 自体の可用性を高める機能をActive/Standby構成にして単一障害点を回避クライアントはActive に仮想IPでアクセスする Standby) 仮想IP PostgreSQLクライアント相互監視 / 情報共有 (Active) 19

20 のwatchdog 自体の可用性を高める機能をActive/Standby構成にして単一障害点を回避クライアントはActive に仮想IPでアクセスする Standby) 仮想IP PostgreSQLクライアント相互監視 / 情報共有 (Active) 20

21 本日お話する内容 Amazon Web Services (AWS) 上でを使って PostgreSQLのHA構成組みました特に難しい話は出てこずベーシックな内容と導入事例のご紹介 1. HA構成とは 2. とは 3. Amazon Web Servicesとは 4. AWS上での+PostgreSQLの導入事例 21

22 クラウドコンピューティングサービスの形態ネットワーク越しに仮想化されたリソースを提供提供するレイヤ別に3つに分類できるメールサーバメールサービス仮想サーバ DBサーバ物理サーバ仮想サーバ IaaS Infrastructure as a Service www Webサーバ PaaS Platform as a Service ブログサービス SaaS Software as a Service 22

23 クラウドコンピューティングサービスの形態ネットワーク越しに仮想化されたリソースを提供提供するレイヤ別に3つに分類できるメールサーバメールサービス仮想サーバ DBサーバ物理サーバ仮想サーバ IaaS Infrastructure as a Service www Webサーバ PaaS Platform as a Service ブログサービス SaaS Software as a Service 23

24 Amazon Web Services (AWS) オンプレミスの仮想化と比較したAWSのメリットオンプレミス AWS 初期コスト必要不要利用コスト余剰リソースにも発生使った分だけインフラ調達数週間数カ月数分スケールアップダウン時間とコストがかかるすぐに対応可能 [オンプレミスと AWS クラウドの違いとはアマゾンウェブサービス AWS 日本語 ] 24

25 Amazon Web Services (AWS) [AWS ベーシックトレーニング-トレーニング資料] 25

26 本日お話する内容 Amazon Web Services (AWS) 上でを使って PostgreSQLのHA構成組みました特に難しい話は出てこずベーシックな内容と導入事例のご紹介 1. HA構成とは 2. とは 3. Amazon Web Servicesとは 4. AWS上での+PostgreSQLの導入事例 26

27 株式会社Gengo様翻訳サービスのクラウドソーシング企業 2009 年東京でスタートアップ 2010 年 76 万ドルの資金調達に成功 2013 年 1200 万ドルの資金調達に成功渋谷にオフィスを移転 27

サービス概要翻訳して欲しい人と翻訳できる人 11000 人以上が登録をマッチング Web サイト上でｏｒ API

28 サービス概要翻訳して欲しい人と翻訳できる人人以上が登録をマッチング Web サイト上でｏｒ API を使って翻訳 [クオリティと生産性を両立するには Gengo ゲンゴ] 28

29 翻訳可能な言語 54 ペア From To 29

30 Gengo様の構成 (Before) PostgreSQL 9.1 on Ubuntu Primary * 1 + Standby * 8 の構成 DBサイズは80GBほど Web Apps LB 30

31 Gengo様の課題 1 スパイクなトランザクションで負荷が高まる 30000トランザクション/1日 API経由の大量の翻訳依頼などで急に負荷が高まる Web Apps LB 31

32 Gengo様の課題 1 スパイクなトランザクションで負荷が高まる 30000トランザクション/1日 API経由の大量の翻訳依頼などで急に負荷が高まる Web Apps LB [2014年9月18日第10回PostgreSQLエンタープライズコンソーシアムセミナー Gengo様スライドより] 32

33 Gengo様の課題 2 ある日稼動系PostgreSQLサーバの仮想イメージが壊れてしまう原因不明一時的にサービス停止に単一障害点の存在が浮き彫りに Web Apps LB 33

34 Gengo様の課題 2 ある日稼動系PostgreSQLサーバの仮想イメージが壊れてしまう原因不明一時的にサービス停止に単一障害点の存在が浮き彫りに Web Apps [2014年9月18日第10回PostgreSQLエンタープライズコンソーシアムセミナー Gengo様スライドより] LB 34

35 Gengo様の課題 3 稼動系サーバがダウンしたら自動フェイルオーバしてほしい Web Apps 側の負荷分散以外に何かよい負荷分散方法はないか JSON型を使いたいのでPostgreSQLを9.3にアップグレードしたい Web Apps LB 35

36 Gengo様の課題多量のトランザクションを負荷分散単一障害点を取り除く自動フェイルオーバ PostgreSQLを9.1 -> 9.3にアップグレードダウンタイムは1時間でおねがいしますの出番 36

37 Gengo様の構成 (After) LB Web Apps (warm standby) 37

38 Gengo様の構成 (After)! K O! K O! OK 多量のトランザクションを負荷分散単一障害点を取り除く自動フェイルオーバ LB Web Apps (warm standby) 38

39 Gengo様の構成 (After) LB Web Apps warm standby? (warm standby) 39

40 AWS のハマりどころ AWSでは仮想IPが使えません 40

41 AWS的対策 SELECT 1 でモニタリング LB Web Apps (warm standby) 41

42 AWS的対策 SELECT 1 でモニタリング AWSのRoute53(DNSサーバを使ってアドレス変更 LB Web Apps AWS AWSのAPIを実行して名前解決の向きを変える 42

43 AWS的対策! K O! K O! OK SELECT 1 でモニタリング AWSのRoute53(DNSサーバを使ってアドレス変更多量のトランザクションを負荷分散単一障害点を取り除く自動フェイルオーバ OK! も LB Web Apps AWS AWSのAPIを実行して名前解決の向きを変える 43

44 導入作業についてダウンタイムは1時間でおねがいしますサービス稼働中に影響のない作業は済ませておくのセットアップ PostgreSQL 9.3のインストール LB Web Apps (warm standby) 44

45 導入作業についてダウンタイムは1時間でおねがいしますサービス停止データベースクラスタのアップデート pg_upgrade コマンドをハードリンクモードで実行(*) (*)万が一の切り戻しを考慮して現行のDBは先にバックアップを取っておく LB Web Apps (warm standby) 45

46 導入作業についてダウンタイムは1時間でおねがいしますサービス停止データベースクラスタのアップデート待機系PostgreSQLの作成オンラインリカバリで済ます LB Web Apps (warm standby) 46

47 導入作業についてダウンタイムは1時間でおねがいします 1時間以内で作業フィニッシュただし作業は全てスクリプトで自動化待機系は少なくとも1つ起動してればOKとする LB Web Apps (warm standby) 47

[2014年9月18日第10回PostgreSQLエンタープライズコンソーシアムセミナー

48 導入作業についてダウンタイムは1時間でおねがいします 1時間以内で作業フィニッシュただし作業は全てスクリプトで自動化待機系は少なくとも1つ起動してればOKとする LB Web Apps [2014年9月18日第10回PostgreSQLエンタープライズコンソーシアムセミナー Gengo様スライドより] (warm standby) 48

49 Gengo様その後 Xenの脆弱性対策に伴う強制インスタンス再起動メンテナンスに巻き込まれる待機系1台を除きPostgreSQLサーバが再起動の自動フェイルオーバでメンテナンスなしで乗り切った LB Web Apps (warm standby) 49

50 その他のTIPS のヘルスチェックがタイムアウトしてまう仮想環境特有のネットワークがプツプツ切れる問題はヘルスチェック時にselect()コールを投げているソースコードにパッチを当ててタイムアウト値を延長した将来的にはユーザが指定できるようになる予定商用クラスタリングソフトウェアはAWSの仮想IP問題にどう対応している NATインスタンスと仮想ネットワークインタフェースとルーティングルールをAWS APIで操作してなんとか仮想IP的な方法を実現試みにでも同様の手法を実験してみたら一応動作したがあまり現実的ではない 50

51 まとめ PostgreSQLの高可用性+負荷分散 on AWS で構築できましたただし AWSでは仮想IPが使えないので代替手段が必要死活監視のタイムアウト値は長めに AWSのメンテナンス再起動は不可避なので対策は考えておく 51

52 オープンソースとともに URL Tel

アジェンダはクラウド上でも十分使えます 1. の概要とはの導入事例で利用される構成 2. をクラウドで使うクラウドサービスの分類 Amazon Web Services による構成例 2

アジェンダはクラウド上でも十分使えます 1. の概要とはの導入事例で利用される構成 2. をクラウドで使うクラウドサービスの分類 Amazon Web Services による構成例 2 をクラウドで利用しようオープンソースミドルウェア最新技術セミナー 2014/03/25 14:10-14:40 SRA OSS, Inc. 日本支社技術開発部正野裕大 1 アジェンダはクラウド上でも十分使えます 1. の概要とはの導入事例で利用される構成 2. をクラウドで使うクラウドサービスの分類 Amazon Web Services による構成例 2 をクラウドで利用しよう

自己紹介 正野 裕大 マサノ ユウタ SRA OSS, Inc. 日本支社 OSS技術グループ 主にAmazon Web Services (AWS) 関連のR&D活動に従事 SRA OSS, Inc. 日本支社 1999年よりPostgreSQLサポートを中心にOSSビジネスを開始 Postgre

自己紹介正野裕大マサノユウタ SRA OSS, Inc. 日本支社 OSS技術グループ主にAmazon Web Services (AWS) 関連のR&D活動に従事 SRA OSS, Inc. 日本支社 1999年よりPostgreSQLサポートを中心にOSSビジネスを開始 Postgre