netezza→redshift - aws...netezza→redshiftへの移行時に実施したこと...
TRANSCRIPT
-
Netezza→Redshift変化への瞬発力と日々の安定運用に向けて
-
Copyright 2020 cocokarafine Inc. All rights Reserved.3
agenda
本日お話しさせて頂くこと
Netezza(オンプレミス)で手間のかかった運用内容
Netezza→Redshiftへの移行
Redshiftの稼働直後に必要だった対応
導入して3年間運用してみて
-
Copyright 2020 cocokarafine Inc. All rights Reserved.4
agenda
その前に・・・
• 自己紹介
• 当社DWHの変遷
• 現在のシステム概要
-
Copyright 2020 cocokarafine Inc. All rights Reserved.5
自己紹介
株式会社ココカラファイン IT・物流開発部 IT開発チーム
中川 淳
役割
• DWH(以後情報系システム)の構築&運用
• データ調査、集計、分析、提案
好きなAWSサービス
• Redshift
• S3
-
Copyright 2020 cocokarafine Inc. All rights Reserved.6
当社情報系システムの変遷
old-dbnow
2020/62017/92013/1
2013年にドラッグストア・調剤薬局事業を運営する販売子会社6社(セイジョー、セガミメディクス、
ジップドラッグ、ライフォート、スズラン薬局、メディカルインデックス)を合併。
これを機に各子会社のPOSデータのフォーマットを統一し、統合DWHを構築。(Netezza)
2017年に運用効率、今後の当社の成長によりスケーラブルに対応できる環境としてAWSを選定して
構築。(Redshift)
-
Copyright 2020 cocokarafine Inc. All rights Reserved.7
当社情報系システムの構成概略
WEBサーバMartSolution
AWS Cloud
Redshift
DirectConnect
ETLサーバtalend
Availability Zone C
VPC
S3
bucket
snapshot
分析
日々連携されるデータ
-
Copyright 2020 cocokarafine Inc. All rights Reserved.8
agenda
本日お話しさせて頂くこと
Netezza(オンプレミス)で手間のかかった運用内容
• 初期構築コスト
• ハード障害対応、部品確保
• バックアップ
• ビジネス要件対応
• Redshiftへ切り替えた結果
Netezza→Redshiftへの移行
Redshiftの稼働直後に必要だった対応
導入して3年間運用してみて
-
Copyright 2020 cocokarafine Inc. All rights Reserved.9
Netezza(オンプレミス)で手間のかかった内容
Netezza初期構築時の検討事項
現調、ラック図作成
初期構築コスト
LANケーブルは何本、何メートル、電源数は?
電源がアメリカ式
初期インストール
搬入経路、高さ制限
バックアップストレージ接続 パラメータ設定重量
ラッキング
-
Copyright 2020 cocokarafine Inc. All rights Reserved.10
Netezza(オンプレミス)で手間のかかった内容
障害時にハード、ソフトなどの一次切り分けをし、担当の保守連絡先に連絡。ハードの場合はデータセンタへ入館申請を行い、必要なら立ち合いを行う。
対応内容
2013/X/X08:35 メールにて4日のバックアップ異常終了を検知。08:40 保守サポートに連絡。案件No:IDAxxxxx08:45 データセンターにてNAS再起動。
再起動後、NAS、Netezzaともに復旧を確認。09:40 保守サポートからの依頼で以下コマンドをNetezzaにて実行。
/nz/support/etc/get_nz_logs_ida_jp -GetSbladeLogs all -start 2013/X/X10:25 取得した「2013XXXX0941.tgz」を保守サポートに送付。10:56 保守からの依頼で以下ログファイルを送付。
/nz/kit/log/sysmgr/sysmgr.log*14:20 保守サポートからの依頼で以下コマンドをNetezza(root)にて実行。
/opt/nec/esmpro_sa/tools/collectsa.sh14:40 取得したログファイル「collectsa.tgz」をIDA保守サポートに送付。17:30 保守サポートから回答。
NetezzaからNAS側にNFSマウントしている時に、NASが何かしらで落ちたか、疎通が取れていない等の状態になった時に、Netezzaからdiskに対して接続を行ったに際に、接続ができなかった為に発生いたします。
NetezzaとしてはNFSマウントしているDiskに接続をしようと(繰り返し)行った為、ハングアップしたような状態となり接続が出来なくなりました。★今後の対応として。NASを再起動する場合、合わせてNetezzaも同時に再起動します。
起票日
2013/X/XX月X日Netezzaで異常終了
障害内容
ハード障害対応、部品確保
-
Copyright 2020 cocokarafine Inc. All rights Reserved.11
Netezza(オンプレミス)で手間のかかった内容
障害発生時の連絡先 ・・・ 一次切り分けをして連絡する必要がありました
問題を切り分けて連絡
Netezza製品
ジョブ管理製品
NAS(ストレージ)製品
9:00~12:0013:00~17:00連絡先:XXXXXX
8:30~17:30連絡先:XXXXXX
8:30~21:00連絡先:XXXXXX
データセンター入館 24H365D連絡先:XXXXXX必要に応じて連絡
ハード障害対応、部品確保
-
Copyright 2020 cocokarafine Inc. All rights Reserved.12
Netezza(オンプレミス)で手間のかかった内容
Netezza バックアップの仕組みを構築していてデータ量の増加で遅延することもあった
フルバックアップ
バックアップ
差分 差分 差分 差分 差分
前回のフルバックアップ削除
Redshift コンソール画面で選択するだけ
フルバックアップ
外部ストレージ
-
Copyright 2020 cocokarafine Inc. All rights Reserved.13
ビジネス要件
Netezza(オンプレミス)で手間のかかった内容
ソフトのサポート期限、部品製造中止、保守期限切れ等により、パフォーマンスに不満がなくても5年程度で刷新せざるを得ない状況になってしまいます。これは例えば来期統合を控えている為システムは1年延長したいという要件があったとしても、単純な延長はできないということを意味します。
XXXソフトバージョン6.8保守サポート期限X月
2016年
2017年型番XXXXのハード保守期限
XXX製造中止、在庫保管期限XX
・・・
2018年1年繰り下げ
新しいビジネス要件を盛り込めない
新しいビジネス要件
ビジネス要件対応
-
Copyright 2020 cocokarafine Inc. All rights Reserved.14
移行動機
ハード選定、データセンタ搬入、ラッキング、インストール作業など初期構築時間がかかる
バックアップ処理に時間がかかる
障害時にファームウェアの更新や部品の交換でシステム停止時間が長い
①
②
③
ビジネス要件とシステムライフサイクルのタイミングが合わない④
AW
S
コンソールから数ステップで構築が可能
2か所の設定でバックアップ取得、世代管理も可能
フルマネージドの為意識する必要がない、必要に応じて数分の再起動程度
①
②
③
必要なタイミングで柔軟に拡張可能、オンデマンドで検証もできる④
Netezza(オンプレミス)で手間のかかった内容
-
Copyright 2020 cocokarafine Inc. All rights Reserved.15
agenda
本日お話しさせて頂くこと
Netezza(オンプレミス)で手間のかかった運用内容
Netezza→Redshiftへの移行
• エクスポート→S3コピー→ロードで間に合わずSnowballを利用
• 並行稼働チェック
• 動かなかったクエリの修正
Redshiftの稼働直後に必要だった対応
導入して3年間運用してみて
-
Copyright 2020 cocokarafine Inc. All rights Reserved.16
Netezza→Redshiftへの移行時に実施したこと
WEBサーバMartSolution
AWS Cloud
RedshiftETLサーバ
talend
Availability Zone C
VPC
S3
bucket
snapshot
Netezza
ストレージ
外部テーブルを作成してexport
Snowball
NetezzaのDDLからcreate table
3TBの移行データ
Netezzaから出力したcreate Table DDLをエクセルに張り付けるとRedshiftのcreate文になるようにしてDDLを作成しました。分散キーの部分は手動で設定しました。
-
Copyright 2020 cocokarafine Inc. All rights Reserved.17
Netezza→Redshiftへの移行時に実施したこと
並行稼働チェック約一か月弱実施
並行稼働チェック
テーブル名 Netezza件数 Redshift件数 Netezza合計 Redshift合計
• 毎日実施
• 週1程度実施
テーブル名 Netezzaサンプリング Redshiftサンプリング
-
Copyright 2020 cocokarafine Inc. All rights Reserved.18
Netezza→Redshiftへの移行時に実施したこと
移行当時のメモです。
・日付 now()は利用不可のため修正が必要です。Netezza:to_char(now() - interval '12 months','yyyyMM')Redshift:to_char(CURRENT_DATE - interval '12 month','YYYYMM')
・時間を取得する場合はgetdate()またはsysdateを使います。UTC時間注意。Redshift:to_char(convert_timezone('JST', getdate()),'yyyyMMdd HH24miss')
・select句にある別名を利用できません。Netezza:select ARARI/ZEINUKI_KIN*100 as 粗利率, 在庫回転率*粗利率 as 交差比率 from
CF_TJOURNALRedshift:select ARARI/ZEINUKI_KIN*100 as 粗利率, 在庫回転率
*(ARARI/ZEINUKI_KIN*100) as 交差比率 from CF_TJOURNAL
動かなかったクエリの修正
・SUBSTR関数は利用できない為SUBSTRING関数を利用する
2020/06 どちらも利用可能
2020/06 SUBSTRINGのみ
2020/06 UTC時間注意
2020/06 別名利用可能
-
Copyright 2020 cocokarafine Inc. All rights Reserved.19
移行課題
3TBの移行データ
並行稼働チェック
SQLの記載方法のちがい
①
②
③
対応
Snowballを利用
テーブル毎に件数、合計、サンプリングチェックを実施
移行時はTry And Errorで対応したが順次対応した
①
②
③
Netezza→Redshiftへの移行時に実施したこと
-
Copyright 2020 cocokarafine Inc. All rights Reserved.20
agenda
本日お話しさせて頂くこと
Netezza(オンプレミス)で手間のかかった運用内容
Netezza→Redshiftへの移行
稼働直後から安定するまでの対応
• Redshiftクラスタが頻繁に再起動
• create table時に依存エラー
導入して3年間運用してみて
-
Copyright 2020 cocokarafine Inc. All rights Reserved.21
Redshiftクラスタが頻繁に再起動
データベース接続
Queries
当時のRedshiftパフォーマンス確認画面
稼働直後から安定するまでの対応
-
Copyright 2020 cocokarafine Inc. All rights Reserved.22
BIツール:MartSolution
AWS Cloud
Redshiftの推奨構成
・・・
BIツール:MartSolution
AWS Cloud
・・・
当社の構成
Redshift
Redshift
AWSサポートからの回答は中間DBを配置してマートテーブルをステージングし、BIツールからの接続は中間DBが受け止める構成だった
1400店舗、全国の事業所スタッフからの接続
1400店舗、全国の事業所スタッフからの接続
中間DB
稼働直後から安定するまでの対応
Redshiftクラスタが頻繁に再起動
-
Copyright 2020 cocokarafine Inc. All rights Reserved.23
BIツール:MartSolution
AWS Cloud
Redshiftの推奨構成
・・・
BIツール:MartSolution
AWS Cloud
・・・
当社の構成
Redshift
Redshift
夜間の更新処理後にあらかじめ発行される想定のクエリを実行してキャッシュを作っておくことにしました。
1400店舗、全国の事業所スタッフからの接続
1400店舗、全国の事業所スタッフからの接続
中間DB
稼働直後から安定するまでの対応
Redshiftクラスタが頻繁に再起動
結果のキャッシュ
クエリを事前実行してキャッシュを
作成
MartSolutionキャッシュ
明け方に当日検索されるクエリを事前実行してキャッシュを作成
-
Copyright 2020 cocokarafine Inc. All rights Reserved.24
Redshiftの運用状況
稼働直後から安定するまでの対応
Redshiftクラスタが頻繁に再起動
-
Copyright 2020 cocokarafine Inc. All rights Reserved.25
当社はBIツールでは賄いきれないワンタイムのスポット分析を実施するユーザに対してODBC接続を許可しています。ODBC接続用のスキーマを作成し、そのスキーマにはVIEWのみを配置しています。VIEWにすることで必要十分な項目のみをユーザに提供できます。
ユーザがODBC接続したままにしていると夜間処理でエラーが発生します。
稼働直後から安定するまでの対応
AWS Cloud
Redshift
BIツール用本番スキーマ
ODBC接続用スキーマ
TABLE
VIEW
TABLE TABLE
VIEW VIEW
BIツール:MartSolution
ODBC:ACCESS
drop table 時に依存エラー
-
Copyright 2020 cocokarafine Inc. All rights Reserved.26
夜間処理ではデータの更新に時間がかかると想定されるテーブルに対してはその間にユーザからのselectがあってもロックされないように別名テーブルを作成してそちらでデータ更新をした後にrenameしています。その際古いほうのテーブルをdropしているのですが、viewで利用しているテーブルだとdropできずにエラーになってしまいます。そのため、夜間処理前にviewをdropしているのですが、ODBC接続したままのユーザがいるとviewがdropできません。
稼働直後から安定するまでの対応
drop table 時に依存エラー
create table CF_NEW
insert into CF_NEW as select * from CF_NOW
delete deom CF_NEWwhere XXXX
insert into CF_NEW as select * from new_data
alter table CF_NOW rename to CF_NOW_DELalter table CF_NEW rename to CF_NOW
drop table CF_NOW_DEL
vacuum CF_NOWanalyze CF_NOW
CF_NOW
CF_NEWデータ更新
VIEW_CF_NOW
CF_NOW_DEL
CF_NOW
CF_NOW_DEL
CF_NOWVIEW_CF_NOW
-
Copyright 2020 cocokarafine Inc. All rights Reserved.27
障害ポイントを減らすために夜間処理前にabort_sessionをするようにしました。
稼働直後から安定するまでの対応
drop table時に依存エラー
23時abort_session
24時drop_view
日次処理後create_view
夜間処理create tablealter table drop_table
-
Copyright 2020 cocokarafine Inc. All rights Reserved.28
稼働時課題
500sessionでクラスタが再起動
drop table 時にview依存エラー
①
②
AW
S
BIツールキャッシュとDBキャッシュの2つで対応
事前のabort_sessionを実施
①
②
稼働直後から安定するまでの対応
-
Copyright 2020 cocokarafine Inc. All rights Reserved.29
agenda
本日お話しさせて頂くこと
Netezza(オンプレミス)で手間のかかった運用内容
Netezza→Redshiftへの移行時のSQL修正
稼働直後から安定するまでの対応
導入して3年間運用してみて
• 現在のコンソール状況
• 3年利用してみて感じたこと
• 今後やってみたいこと
-
Copyright 2020 cocokarafine Inc. All rights Reserved.30
10秒未満のクエリ :494110秒以上10分未満のクエリ :7210分以上のクエリ :3
午前 午後夜間 深夜
2020/05のawsコンソール状況
現在のコンソール状況
導入して3年運用してみて
-
Copyright 2020 cocokarafine Inc. All rights Reserved.31
導入して3年間運用してみて
3年利用してみて感じたこと
Redshiftを3年運用してみて感じたこと
• ハードウェア障害に関するリスクやコストを見積もる必要がなくなった
• オンプレミスでは時間の経過と主に性能が下がっていくが、Redshiftは常にシステム改善されていくので
性能が上がっていく
• ビジネス要件ありきでシステム変更をすることができる
-
Copyright 2020 cocokarafine Inc. All rights Reserved.32
導入して3年間運用してみて
今後やってみたいこと
今興味のあるサービスはRedshiftのRA3構成です。
• ds2.xlargeの7nodeをやめてra3.4xlargeの2nodeに乗り換えた場合のパフォーマンスはどうか
• コンピューティングとストレージが分離したので要件にフィットした性能と容量が選択できる
ds2.xlarge7node
ra3.4xlarge2node Managed Storage
• ストレージ :14TB• vCPU :28• メモリ :224
• ストレージ :14TB• vCPU :24• メモリ :192
7node
2node
現在構成
興味あり