Netezza→Redshift - AWS...Netezza→Redshiftへの移行時に実施したこと...

Netezza→Redshift変化への瞬発力と日々の安定運用に向けて

Copyright 2020 cocokarafine Inc. All rights Reserved.3

agenda

本日お話しさせて頂くこと

Netezza(オンプレミス)で手間のかかった運用内容

Netezza→Redshiftへの移行

Redshiftの稼働直後に必要だった対応

導入して3年間運用してみて


agenda

その前に・・・

• 自己紹介

• 当社DWHの変遷

• 現在のシステム概要


自己紹介

株式会社ココカラファイン IT・物流開発部 IT開発チーム

中川淳

役割

• DWH(以後情報系システム)の構築＆運用

• データ調査、集計、分析、提案

好きなAWSサービス

• Redshift

• S3


当社情報系システムの変遷

old-dbnow

2020/62017/92013/1

2013年にドラッグストア・調剤薬局事業を運営する販売子会社６社（セイジョー、セガミメディクス、

ジップドラッグ、ライフォート、スズラン薬局、メディカルインデックス）を合併。

これを機に各子会社のPOSデータのフォーマットを統一し、統合DWHを構築。(Netezza)

2017年に運用効率、今後の当社の成長によりスケーラブルに対応できる環境としてAWSを選定して

構築。(Redshift)


当社情報系システムの構成概略

WEBサーバMartSolution

AWS Cloud

Redshift

DirectConnect

ETLサーバtalend

Availability Zone C

VPC

S3

bucket

snapshot

分析

日々連携されるデータ


agenda



• 初期構築コスト

• ハード障害対応、部品確保

• バックアップ

• ビジネス要件対応

• Redshiftへ切り替えた結果





Netezza(オンプレミス)で手間のかかった内容

Netezza初期構築時の検討事項

現調、ラック図作成

初期構築コスト

LANケーブルは何本、何メートル、電源数は？

電源がアメリカ式

初期インストール

搬入経路、高さ制限

バックアップストレージ接続パラメータ設定重量

ラッキング



障害時にハード、ソフトなどの一次切り分けをし、担当の保守連絡先に連絡。ハードの場合はデータセンタへ入館申請を行い、必要なら立ち合いを行う。

対応内容

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で異常終了

障害内容

ハード障害対応、部品確保



障害発生時の連絡先・・・一次切り分けをして連絡する必要がありました

問題を切り分けて連絡

Netezza製品

ジョブ管理製品

NAS(ストレージ)製品

9:00～12:0013:00～17:00連絡先：XXXXXX

8:30～17:30連絡先：XXXXXX

8:30～21:00連絡先：XXXXXX

データセンター入館 24H365D連絡先：XXXXXX必要に応じて連絡

ハード障害対応、部品確保



Netezza バックアップの仕組みを構築していてデータ量の増加で遅延することもあった

フルバックアップ

バックアップ

差分差分差分差分差分

前回のフルバックアップ削除

Redshift コンソール画面で選択するだけ

フルバックアップ

外部ストレージ


ビジネス要件


ソフトのサポート期限、部品製造中止、保守期限切れ等により、パフォーマンスに不満がなくても5年程度で刷新せざるを得ない状況になってしまいます。これは例えば来期統合を控えている為システムは1年延長したいという要件があったとしても、単純な延長はできないということを意味します。

XXXソフトバージョン6.8保守サポート期限X月

2016年

2017年型番XXXXのハード保守期限

XXX製造中止、在庫保管期限XX

・・・

2018年1年繰り下げ

新しいビジネス要件を盛り込めない

新しいビジネス要件

ビジネス要件対応


移行動機

ハード選定、データセンタ搬入、ラッキング、インストール作業など初期構築時間がかかる

バックアップ処理に時間がかかる

障害時にファームウェアの更新や部品の交換でシステム停止時間が長い

①

②

③

ビジネス要件とシステムライフサイクルのタイミングが合わない④

AW

S

コンソールから数ステップで構築が可能

2か所の設定でバックアップ取得、世代管理も可能

フルマネージドの為意識する必要がない、必要に応じて数分の再起動程度

①

②

③

必要なタイミングで柔軟に拡張可能、オンデマンドで検証もできる④



agenda




• エクスポート→S3コピー→ロードで間に合わずSnowballを利用

• 並行稼働チェック

• 動かなかったクエリの修正




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を作成しました。分散キーの部分は手動で設定しました。



並行稼働チェック約一か月弱実施

並行稼働チェック

テーブル名 Netezza件数 Redshift件数 Netezza合計 Redshift合計

• 毎日実施

• 週1程度実施

テーブル名 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 別名利用可能


移行課題

3TBの移行データ

並行稼働チェック

SQLの記載方法のちがい

①

②

③

対応

Snowballを利用

テーブル毎に件数、合計、サンプリングチェックを実施

移行時はTry And Errorで対応したが順次対応した

①

②

③



agenda




稼働直後から安定するまでの対応

• Redshiftクラスタが頻繁に再起動

• create table時に依存エラー



Redshiftクラスタが頻繁に再起動

データベース接続

Queries

当時のRedshiftパフォーマンス確認画面



BIツール：MartSolution

AWS Cloud

Redshiftの推奨構成

・・・


AWS Cloud

・・・

当社の構成

Redshift

Redshift

AWSサポートからの回答は中間DBを配置してマートテーブルをステージングし、BIツールからの接続は中間DBが受け止める構成だった

1400店舗、全国の事業所スタッフからの接続


中間DB





AWS Cloud

Redshiftの推奨構成

・・・


AWS Cloud

・・・

当社の構成

Redshift

Redshift

夜間の更新処理後にあらかじめ発行される想定のクエリを実行してキャッシュを作っておくことにしました。



中間DB



結果のキャッシュ

クエリを事前実行してキャッシュを

作成

MartSolutionキャッシュ

明け方に当日検索されるクエリを事前実行してキャッシュを作成


Redshiftの運用状況




当社はBIツールでは賄いきれないワンタイムのスポット分析を実施するユーザに対してODBC接続を許可しています。ODBC接続用のスキーマを作成し、そのスキーマにはVIEWのみを配置しています。VIEWにすることで必要十分な項目のみをユーザに提供できます。

ユーザがODBC接続したままにしていると夜間処理でエラーが発生します。


AWS Cloud

Redshift

BIツール用本番スキーマ

ODBC接続用スキーマ

TABLE

VIEW

TABLE TABLE

VIEW VIEW


ODBC：ACCESS

drop table 時に依存エラー


夜間処理ではデータの更新に時間がかかると想定されるテーブルに対してはその間にユーザからの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_NOWａｎａｌｙｚｅ CF_NOW

CF_NOW

CF_NEWデータ更新

VIEW_CF_NOW

CF_NOW_DEL

CF_NOW

CF_NOW_DEL

CF_NOWVIEW_CF_NOW


障害ポイントを減らすために夜間処理前にabort_sessionをするようにしました。


drop table時に依存エラー

23時abort_session

24時drop_view

日次処理後create_view

夜間処理create tablealter table drop_table


稼働時課題

500sessionでクラスタが再起動

drop table 時にview依存エラー

①

②

AW

S

BIツールキャッシュとDBキャッシュの２つで対応

事前のabort_sessionを実施

①

②



agenda



Netezza→Redshiftへの移行時のSQL修正



• 現在のコンソール状況

• 3年利用してみて感じたこと

• 今後やってみたいこと


10秒未満のクエリ：494110秒以上10分未満のクエリ：7210分以上のクエリ：3

午前午後夜間深夜

2020/05のawsコンソール状況

現在のコンソール状況

導入して3年運用してみて



3年利用してみて感じたこと

Redshiftを3年運用してみて感じたこと

• ハードウェア障害に関するリスクやコストを見積もる必要がなくなった

• オンプレミスでは時間の経過と主に性能が下がっていくが、Redshiftは常にシステム改善されていくので

性能が上がっていく

• ビジネス要件ありきでシステム変更をすることができる



今後やってみたいこと

今興味のあるサービスはRedshiftのRA3構成です。

• ds2.xlargeの7nodeをやめてra3.4xlargeの2nodeに乗り換えた場合のパフォーマンスはどうか

• コンピューティングとストレージが分離したので要件にフィットした性能と容量が選択できる

ds2.xlarge7node

ra3.4xlarge2node Managed Storage

• ストレージ：14TB• vCPU ：28• メモリ：224

• ストレージ：14TB• vCPU ：24• メモリ：192

7node

2node

現在構成

興味あり

Netezza→Redshift - AWS...Netezza→Redshiftへの移行時に実施したこと...

Documents

Transcript of Netezza→Redshift - AWS...Netezza→Redshiftへの移行時に実施したこと...