オープンソースカンファレンス2015　Hokkaido

ということで、今回は本土を飛び出し北海道！のラーメンを食べに行くついでに、OSCカンファレンスに行って喋ってきましたよ。

概要

各セッション概要

俺が聞いたセッションは以下。

プログラミング言語Elixir
  • 講師は にく さん
    • あ、俺以外にも偽名での発表者いたのね。
  • この時間帯はDB関連のセッションがなかったので、なんとなく面白そうなテーマを選んで聞いてみる。
  • 関数型プログラミング
  • Erlang互換/ErlangVMで処理
  • Rubyに似た構文？
  • アトムとはなんぞや。「自分の名前が自分の値を表すような整数」⇒なんぞその説明ｗ
    • enumみたいなものか。
  • この言語の立ち位置というか目的が良く分からなかった・・・最近、新しいプログラミング言語に全くついていけてないな(´・ω・｀)
Postgresへのスマートなデータ移行とアプリケーション開発
  • 11:00からのセッションはPostgresへのデータ移行/アプリケーション開発。講師は佐瀬さん＠アシスト アンケート書くと本がもらえるらしい。
  • まず移行のステップ論と各ステップで適用できるツールやサービスの説明。
  • Oracle Migration Assesment(OMA)はは資料上は有償と書かれているが、今は無償サービスになったとのこと。
    • 移行準備と移行テストでは、SI Object Browserが使える。有償だけど、30日は無償で使えるらしい。ドーラ「30日で移行しな！」
  • SI Object BrowserはGUIのツールのデモ。実際のデータベース(Oracle)に接続してリバース・エンジニアリングして、ER図を自動生成する。
    • で、VARCHAR2やsysdateなどの問題にどうツールで対応するのかと。このツールではデータ型変換で対応。なお、このツールはOracle/PostgreSQLだけでなく、MySQLなども移行先に選択可能。
    • 自動変換すると、sysdateをnow()に一括変換するなどをやってくれる。
    • 変換後にPostgreSQLに接続して生成したスキーマ情報を流し込む。流し込んだ後、確認も可能。VARCHAR2はvarcharに単純置換してるっぽい。
    • データ生成ツールなんかも、このツールでサポートしている。日本語ランダムデータの生成機能は何気にあると嬉しいんだよな。
  • 次は、Postgres Plus Migration Toolkit(MTK)の説明。
  • EDB*loaderはOracle*LoaderのPostgreSQL版。要はパラレルローダ。でも、ロード元の分割を自分でやらないといけないのはイケてないと思う。
    • DB*Loader 12並列でロードした場合、1並列と比べると6倍速い。並列度を上げると実際速い。
  • その後はｘDB Replicationの説明。シングルマスタ構成/マルチマスタ構成がとれる。
  • EMigration ToolkitとxDB Replicatoinを組み合わせて、システム停止を最小限に抑えるデータ移行を検討する必要がある。業務知識ももちろん必要。
  • 最後はPostgres Enterprise Manager(PEM)の説明。よーするに、PostgreSQL版OEM。
    • PEMのインデックスアドバイザはちょっと気になる。
    • PEMのオブジェクトブラウザや監視画面は、まあ一通りサポートしているという感じか。DBを選択して、DB単位でもうちょっと詳しい情報も取れるっぽい。
    • でも、実際のところ膨大なグラフとかだけ見せられても判断できんこと多いんじゃないかなー。何が起きているかを経験則的に判断して、運用者にアクションをとるべきかを簡易に判断できるサマリ作ってくれるツールはないものかなあ。
  • QA. せっかくなので質問する。インデックスアドバイザは、PEM接続先が普通のPostgreSQLでも使えるものなんだっけ？
    • ⇒インデックスアドバイザは接続先がPPASでしか使えない。PPAS内にインデックスアドバイザ拡張を入れてるため。
    • まあ、概ね予想通りの回答ですた。
Intermission
  • 昼食はコンベンションセンターから歩いて10分くらいの場所にあった、「味の東一」というお店の味噌ラーメン。
    • 西山製麺の縮れ麺。
    • 純連・すみれ系と比べるとかなりあっさり系の味噌。
    • でもこれはこれで悪くない。具もほどほどに多い。
    • これで550円なら実際安い。


高トランザクションシステムへのPostgreSQL適用事例＆Postgres Plus最新動向
  • 13時からのセッション。EnterpriseDBプロダクト最新動向 講師は高鶴さん@EDB社
  • 前半はEDBの話。後半はEDBの事例紹介。事例紹介は富士通SSL社から。
  • たしかにEnterpriseDB社の中の人にはMajor contributor多いもんなあ。
  • なるほどね。富士通SSL社がEDB社と協業して日本向けのサポートをしていると。
  • PPASでの拡張機能は、PostgreSQLの次期バージョンに取り込むというコミュニティ活動も実施している。IndexOnlyScanやマテビューもEDB主導。
  • EDBのBack and Recovery Toolとpg_rman比較って誰かやってたっけ・・・？
  • Pacemakerを使わないというFailover Managerが気になる。
  • PPAS 9.4ではハッシュパーティションを実現してるのか！
  • PPAS 9.5ではFDWパッケージ拡張として、Mongo, MySQL, Hadoopも対象とするのか。
  • おやあ、シャーディングの話って9.6に入ってるな。9.5のFDW inherit＋postgres_fdw方式でないシャーディングに対応するってことかえ？
    • 海外さんからRTが。 @kkaigai Funnel Executor + Partitionとかじゃないですか？
  • PEM 6.0の話。Nagious統合なども検討してるっぽい。
  • xDB Replication 6.0では、ロジカルデコーディング機構も取り込むみたい。
  • Backup and Recovery ToolのBART機能でバックアップの煩雑な手順を支援すると。そういえばpg_rmanのGUIコンソールとかって、コミュニティじゃ対応はしないのかな。
  • 後半からPPASを使った高トランザクション案件への適用事例紹介。
  • 紹介するPPAS適用事例は、ソシャゲの課金/決済システム。24H365D、数百GBスケールの案件。
  • PPASの適用理由。PostgreSQLを利用、サポート、プロがいる、独自の性能改善など。
  • PostgreSQL 9.2時点でも80コアまでのスケールアップは確認できた。つーか、PGEcons検証でやってたらしい。
  • 高トランザクション時にレプリケーションはどうする？課金決済システムでは更新性能は落ちるが、データ一貫性を保証するため同期レプリケーションを選択。
  • レプリケーションのNW負荷については、専用D-LANを使って対応。
  • ベースバックアップ取得時の工夫。バックアップはローカルストレージに取得。空き時間にバックアップサーバに転送。
  • アーカイブログ領域の逼迫をどう防ぐか。机上計算による1日あたりのWALファイル料の算出してディスク設計をきちんとしておく。もちろん監視も重要。
  • サービス停止時間短縮の件。意外にもSlony-Iを使ったレプリケーションを設計してサービスを停止せずに移行した。
  • まとめ、PostgreSQLの機能には問題なし。運用設計は必要。
  • EDB社のノベルティ。 EDBロゴ入りケースに入った付箋紙でした。
PostgreSQLの監視運用を楽にするツールのご紹介 〜 pg_monz と fluentd 〜
  • 14時からのセッション。pg_monzとfluentdの話。講師は中西さん@TIS
  • 中西さんも今日は仕事で着ているので、TIS社の宣伝が入るｗ
  • テーマはPostgreSQL標準機能による監視、pg_monzによる監視、fluentdの利用。
  • まず、データベースの運用管理の基本の話。死活監視、リソース監視、性能、バックアップ/リストア。今日はその中で監視にフォーカス。
  • PostgreSQLの監視に使うのは稼働統計情報とログ。
  • 稼働統計情報をSQLで書くのはダルいｗ あと、差分をとるのは一工夫が必要。
    • ということでツールを使おう⇒ZABBIX/pg_monzを使おう的な流れ。
  • pz_monzはTISとSRA OSSで共同開発したと。中西さんも開発メンバの一人。
  • pg_monzでできること。死活監視、接続関連、Tx量、エラーメッセージ、CP実行状況、容量、テーブル等の稼働状況、キャッシュヒット率など。
  • pz_monz 2.0ではクラスタ監視が追加。SR状態。FOイベント通知、STBデータ遅延状況、同期先プライオリティ。
    • pg_monzってフェイルオーバイベントの通知って、何を元に判断しているんだろう・・・promoteのログから判断してるのかなあ？
    • pg_monzではpgpool-II状態も監視できる。あと、重要な機能はクラスタ系全体で不整合になっていないかを監視可能。スプリットブレイン、更新不可能状態(primary不在)の検知など。
  • ZABBIXとpg_monzの関係図の説明。SR構成の場合もほぼ同じ。ただ、SR専用のテンプレートとSRクラスタというテンプレートをZABBIXサーバに登録する。pgpoll-II用もだいたいおなじ
  • 次はPostgreSQLログの話。出力レベルに応じたログ、処理されたSQL、スロークエリ。CPや自動バキューム、デッドロック検知などのイベント。
  • PostgreSQLログのイケてないところ。古いログのメンテはローテーションのみ。クリーンナップは他のツール。通知機能がない。ログのルーティング機能がない。1つのファイルに吐き出すので分析しづらい。
  • ZABBIX＋pg_monzでログ監視は細かいところまでは難しい？
  • ログを分析しやすい形にできないか→じゃあ、fluentdという流れ。
  • fluentdの概説。データソースはDB、ファイル、クラウドからAPIで取得したリソースなどinput-plugin- で、出力先もoutput-pluginで柔軟に構成が組める。
  • FluentdでPostgreSQLログ(CSV)をPostgreSQLのDBにJSONとして格納するという例の説明。
    • tag-filterや、paserのプラグインは、やっぱり正規表現職人が必要なのかな。
    • ここでPostgreSQLのJSONの話。詳しくはぬこのセッションを聞いて、という振られかたをされるとかｗ
  • まずは使ってみましょう！というお誘い。github管理なので直接プルリク送ってもいいよーとのこと。試行環境のVirtualBoxやVargrantのイメージも提供。6台のVMを上げるので、メモリ等は結構必要・・・6台ｗｗｗ
PostgreSQLトラブルシュート
  • 15時15分からのセッション。PostgreSQLトラブルシューティング。講師は山田さん＠アシスト
  • 問合わせのうち、何が解決できない・解決しにくい問合わせなのか。それはどうすれば解決するのかがテーマ。 #postgresql わりと他人事ではないテーマ。
  • アシストさんの会社紹介をしないと、講師の山田さんの出張代がでないという非情な現実ｗ
  • アシストさんへのPostgreSQL問合わせ件数は年間1500件。3/4は製品QA。それはなんとなく分かる気がする。 #postgresql 某商用データベースのほうがトラブル対応の割合が多い。
  • 某商用データベースの情報はWeb上に転がっている説。PostgreSQLは、まだ公開ノウハウが少ないのかなあ。個人的にはPostgreSQL文書はそこそこ充実している気はするんだけどなあ。慣れの問題かもしれないけど。
  • PostgreSQLの製品QAの解決率が100%なのは、ソースを見れるからという説。もちろんソースを読める技術者が(広義の)社内にいるから、なんだろうけど。
  • やっぱりlog_min_durationの設定はやっぱり大事だよねーという話。
  • ロックやハングアップはログに出ない。情報がないので迷宮入りしやすい。再起動前に情報収集を行う- と。今日のメインテーマは、このロックやハングアップ問題。
  • まず、ロック競合の確認。pg_stat_activity/pg_locksを見なさいよと。
  • pgrowlocks関数とlog_lock_waitsパラメータの紹介。9.4からはロック獲得中の加害者側もログ出力されるようになったので、解析が楽になりそう。
  • ハングアップ＝不適切な実行計画。EXPLAINやpg_stats_all_tablesの説明。pg_stats_all_tablesでは最終ANALYZE時間に注意重点な。
  • enable_* パラメータによる結合方式変更の話。でも、これって商用運用環境ではなかなか使いづらい手段のような気もするよなあ。開発途中なら問題はないだろうけど。
  • contrib/auto_explainも使えるかもという補足。
  • OSリソースからの分析の話。プロセス数超過、特定プロセスの資源専有、全体的なリソース使用状況など。でも、これって、銀の弾丸的な解析方法ってないんだよなあ・・・
  • pg_statsinfoの話も出た。pstackってなんだっけ？スピン(ロック？)の検出とかに使うのかな？
  • PPASでは、pg_stastinfo相当の機能が入っている。さらに、待機イベントも確認ができる。素のPostgreSQLでは使えないので注意重点な。
  • ここから問合わせ事例の話。ハング状態発生したけど、情報取得前にDB再起動。情報が取れないので迷宮入り。一ヶ月後に再現したので、情報を取得してもらって解析。(つづく)
  • 調査を進めていくとロングトランザクションが原因だった。不用意に処理は終了しているけど、トランザクションを終了させていなかったケース。アカンAPあるあるパターン。
  • 運用サイドへの教訓。障害情報収集のための手順はスクリプト化しておこう。
  • 次の事例はセッション数増加で高負荷になった。OS側情報(このケースではperf)の結果を元に確認。解析の結果、非常にスピンロック待ち。その原因として、THPの背景でメモリコンパクションが発生。このときに、一時的に待機する。THP起因？
  • THPの件、QAで聞いてみた。この問題の場合、THPをOFFることで回避したらしい。THP問題・・・私、気になります！
PostgreSQLで非構造化データを使う --- XML, hstore, JSON, JSONB
  • ぬこの発表。
    • 聴講者は20名くらい？思ったより少なかった・・・
  • スライドはこちら⇒Osc2015 hokkaido postgresql-semi-stuructured-datatype
    • スライド160枚超はやっぱり45分の発表では多すぎ・・・後半、だいぶ端折ってしまった。反省。
  • 発表後、JSONスキーマは使わんの？と質問される。今のところ、コミュニティも含めて検討はしてないさげ、と回答する。

ライトニングトーク

OSCのLT、いろんな意味でレベルたけえ・・・

  • 銅鑼娘(男)・・・
  • LT 1本目。情報格差の話。5分で63枚ｗｗｗ 最後は釧路グルメガイドw
  • LT 2本目 床テープ貼り機・・・？ ライトニングパントマイム・・・？
  • LT 3本目 FirefoxOSのはなし
  • LT 4本目 テーマは 「私 vs プログラミング」ｗｗｗ 趣味のアセンブラで綺麗にまとめたw
  • LT 5本目 300円でBadUSB・・・が、これは仮の姿ｗ
  • LT 6本目 Djangoフレームワーク
    • 「いつものことだし」( ´・ω・`) でも、Python自体は結構周りにも使ってそうな人、いるんだけどなあ。
  • LT 7本目 CircleCI紹介 CircleCIはDocker対応、コンテナ1つなら無料。sshログイン可能。CI入門向き。
  • LT 8本目 攻めのテスト JaSST。日本ソフトウェアテストシンポジウムの略。今年のテーマは「バグを狙い撃つ」
    • うちの会社も社内研修でテスト関連の研修やるだけでなく、こういうシンポジウムにどんどん参加させる雰囲気を作ればいいのに。(少しだけまじめに)
  • クロージング恒例？じゃんけん大会。
    • 今回の景品はミクさん最新バージョン？
    • まさかのチョキ4連続w しかしそれを切り抜けた猛者が一人！見事にミクさんGet!

懇親会

  • 懇親会はサッポロビール園でした。
  • つーか、懇親会で170人とかｗ
  • 麦酒とジンギスカンでウマー。
  • 懇親会中にLTあり、つーか懇親会中にLTスライド作る北海道クラスタコワイ！
  • 懇親会会場にタブレットを忘れるという大失態ｗｗｗ
    • しかも俺のタブレットがツイートで晒されるというｗ
    • 札幌駅で気づいて、タクシーで慌ててビール園に戻る。
    • 無事、回収できました。矢地さん、本当にありがとうございました！