サーバー・ネットワーク構築の仕事

日本最大級のクラウドソーシング「ランサーズ」なら、YAMAHA RTX1200ルーターとAWSのVPN接続の仕事を依頼できます。質の高いサーバー・ネットワーク構築のプロが多数登録しており、納期・価格・細かいニーズにも対応可能。会員登録・発注手数料は無料です! 続きを読む

中途入社のAWSエンジニアが、稼働中サービスの運用状況をキャッチアップするために意識すること

Classiアドベントカレンダー11日目です。
今回は、AWSエンジニアが稼働中のAWSの管理アカウントを渡されて、ビクビクしながらキャッチアップを行っていったときのメモになります。

1.TL;DR

AWSアカウントのログイン前に準備できることもあるし、AWSアカウントにログインしてわかることもあるし、サーバーにログインしてわかることもある。それぞれのレイヤーでどういったことを確認するかを意識しながらキャッチアップを進めていきましょう。

2.AWSアカウントログイン前の事前準備

pre_aws.png

サービスが稼働しているのであれば、AWSアカウントにログインせずとも、たくさんの情報をキャッチアップすることができます。1日目から何らかの大きなアウトプットを出さないと解雇するような会社は、(おそらく)存在しない筈です。まずは落ち着きましょう^^;

2-1.ドキュメント読み込み

サービスのインフラにAWSが使われることが多くなったからといって、入社前に経験したAWS運用フローがそのまま活かせる訳ではありません。まずは、前任者や運用中のドキュメント管理ツールの中から、今までどのような運用を行っていたかを確認します。
ドキュメントを見たときに意識する観点としては、

  • フロー型:時間による鮮度の劣化があるドキュメント
  • ストック型:システム仕様など、メンテナンスが求められるドキュメント

どちらの情報であるかを意識して読むことが重要です。
フロー型の情報は、障害などで一時的な対応用にメモっていることもあり、運用の中で解決済みのことがあります。そのため、ストック型のドキュメントを中心に見ることが素早いキャッチアップになると思います。
とはいえ、ドキュメントの全てがメンテナンスされている会社というのは稀だと思いますので、各種ドキュメントを見ながら、仮説程度に自分なりのシステム構成図などを書いてみましょう。
要件定義書や各種構成図の変更履歴、課題管理表、リスクコントロール表といったドキュメント類があるのであれば、目を通しておきましょう。

2-2.運用フローを観察する

サービス側のドキュメントについては、まだ文書化されてることが多いですが、運用系ツールに関しては、ドキュメント化されていないことがあります。今の開発スタイルであれば、何らかのチャットツール(Slack,ChatWork,HipChat)上で、

  • デプロイ
  • 各種の通知
  • 運用Bot

の運用といったことが行われていると思います。また、チャットだけでなく、メールでの運用フローも存在しているかもしれません。
こうした運用系ツールの存在は、今後自分がリファクタするときに、「必須要件ではないが、重宝している」ということで、「リファクタ後にも、あの機能を実装して欲しい」といった声が社内から上がると思います。
そのため、このような運用フローがどこで実装されているかを見極めることが重要になってきます。

2-3.インフラ部分のコード読み

「俺はフルスタックエンジニアだ!」という強い意思がある方は、この時点で稼働中のアプリ側のコードまで読み込んでいただければよいですが、まずは入社前に期待されたであろう、インフラまわりのコード化部分を把握しておきましょう。どのみち、いずれはメンテナンスを任されたり、質問されることが増えてきますので、自分のメンテナンスする部分を優先的に確認しておきましょう。
実サーバーの運用はAWSに任せているので、ここで意識しておくことは、

  • Infrastructure Orchestration Tools:Terraform, CloudFormationなど
  • Server Configuration Tools:Chef,Ansible,Itamaeなど

あたりのコードがgithubなどに保存されているからといって、メンテナンスされていない可能性もあります。
コードの設計方針などを確認するのは当然必要なのですが、コードの変更履歴が年単位で放置されていないかどうかも見ておきましょう。特に、AWS関連のコードについては、担当する人がアプリ側よりも少ないので、構築当初のコードのままなのか、運用されているコードなのかはPRなどで確認しておいた方がよいです。

3.AWSのアカウント内を調査する

aws_kansatsu.png

実際にAWSアカウントにログインしたり、APIで各種設定を確認していきます。Web系サービスであれば、TCP/IPモデルやC/Sモデルを意識しながら、下層レイヤー回りから調査していき、ネットワークがどうせ設定されているかを確認していきます。
おそらく、ここで多くの疑問(場合によっては、絶望)が生まれる段階です。「あれ?ドキュメントにこう記述されているけど、設定上は違うような…」という沼にハマることがあるでしょう。負けないでください、一人で抱え込まずに闇を共有できる仲間を見つけましょう。

3-1.外部システム連携の確認

関連するAWSサービス

VPC関連のサービスを中心に、自AWSアカウント以外の連携がないかの確認を行います。

関連しやすいAWSサービス例)

  • DirectConnect
  • NAT Gateway
  • Peering Connection
  • Customer Gateways
  • Virtual Private Gateways
  • VPN Connections
  • NetWorkACL
  • SecurityGroup
  • EIP

などに、何らかのインスタンスが稼働していて、productionやhonbanなどの文言がついたものがあれば、それはドキュメント上には存在しないが、サービス上何らかの理由で稼働しているものである可能性があります。
自社のサービスがAWSアカウント内だけで完結しているのであればよいのですが、誤ってここのインスタンスなどを削除すると、場合によってはシステム復旧できないぐらいの痛手になるので、慎重に確認していきましょう。
特に、SecurityGroupは、最近でこそInboundルールにDescriptionをつけられるようになりましたが、数年運用されているシステムには、何で利用しているIPアドレスなのかがわからないことがあるので、設定確認中に不明なIPアドレスを見つけたら社内で有識者に聞いてみましょう。

3-2.システム導線の確認

関連するAWSサービス

インスタンス障害があるとユーザー影響がありそうな、システム導線を追っていきます。

関連しやすいAWSサービス例)

  • ELB(CLB,ALB,NLB)
  • CloudFront
  • EC2
  • ElasticCache(redis,memcached)
  • RDS(Aurora,MySQL,PostgreSQL,SQLServer)
  • ElasticSearch
  • DynamoDB
  • S3

各種のインスタンスサイズが適切かを確認するのはもちろんですが、DB関連についてはバックアップ関連の設定がちゃんと行われているかどうかも確認しておきましょう。バックアップウィンドウの世代数やメンテナンスウィンドウの時間が営業時間内になっているとかは、結構ありがちな設定漏れケースになります。パラメータストアの設定については、本番で稼働している設定が正義なので、設計と違う場合は、社内で経緯を追ってみましょう。

3-3.運用導線の確認

関連するAWSサービス

直接のユーザー影響はないものの、バッチ系およびログインやログ連携など、システム運用で必要な運用導線を追っていきます。

関連しやすいAWSサービス例)

  • EC2
  • Lambda
  • ElasticSearch(& kibana)
  • IAM
  • CloudTrail
  • AWS Config
  • CloudWatch Logs
  • S3
  • Glacier

24224というポート開放を見れば、そのシステムはfluentd関連のフローがあるのはほぼ確定なので、ログの発生から可視化ツールおよびバックアップのフローまで追っていきましょう。また、バッチ系のEC2に関しては、最近のAWSだと、FargateやECS、Lambdaなどで定期バッチを行うことも可能なので、単一障害点をなくすことができないか、今後の計画のために、バッチ系が整理されているドキュメントなどを探してみましょう。

4.サーバー内の設定を確認する

server_chosa.png

最近だと、Server Configuration Toolsが大分普及していたり、コンテナ系の運用が発達してきているので、このあたりのキャッチアップ期間が少なくなるのかなと思います。とはいえ、SSH接続を頻繁に行うサーバーや起動時間が長いサーバーだと、コードの設定と異なる部分が出てきていることがあるかもしれません。
OSの設定やミドルウェアのバージョンなど、SSH接続すると確認した方がよいところは多々ありますが、Server Configuration Toolsの設定と異なっていたり、運用中のアラート設定などで差異がでやすそうな部分を以下に記載します。

4-1.各種メトリクス確認

メモリやプロセスの状況は、通常CloudWatchだけではわからないので、MackerelやZABBIXなどの監視ツールエージェントを入れているのであれば、各サーバーのメトリクスを確認しておきましょう。

4-2.稼働プロセスの確認

pstreeなどで、稼働しているプロセスを確認します。SSH接続が禁止されているのであれば、AWSのSSMエージェントなりで確認できないかを検討してみましょう。設計上のソフトウェアスタックに存在しないプロセスが常駐している場合は、何のエージェントが動いているかを追っておきましょう。

4-3.不要なファイルが出力されていないかの確認

ログレベルがデバッグのままだったり、ログファイルのローテートがなされていない場合があり、アラートは上がっていないけど、サーバー内のリソースを侵食しているときがあります。また、生成されるログファイルが小さすぎると、ディスクに余裕がありそうに見えても、inodeが先に枯渇するときもあります。lsofdf -iなどを可視化するなどして、サーバー内のディスク状況を確認しておきましょう。

4-4.同期処理と非同期処理のプロセス確認

同期処理のプロセスは意識しやすいので、監視対象に入っている可能性が高いです。ただ、非同期系プロセス(Rubyだとsidekiq,Pythonだとcelery,PHPだとphp-resqueなど)が監視対象に入っていないこともあるので、どのサーバーで非同期処理が行われているかを把握しておきましょう。

5.まとめ

AWSや他のパブリッククラウドが全盛になった今でも、3層アーキテクチャのシステム構成やOSI7階層などのレイヤーを意識しながらキャッチアップを行うと、システムを俯瞰しながらキャッチアップを進めることができるのではないかなと思います。とはいえ、前任者がコード化しきれなかった部分もある筈なので、そこは社内で過去経緯を知っている人に笑顔で質問をしてみましょう。技術が発達しても、人に蓄積されるノウハウはまだまだ多いので…
AWSエンジニアが転職する際などのご参考になれば。

続きを読む

ドローンが残業者を監視&退社を催促、「T-FREND」来春サービス開始

また、NTT東日本が提供する通信回線「ギガらくWi-Fi」「フレッツVPNプライオ」「クラウドゲートウェイクロスコネクト」を組み合わせることで、インターネット回線を使わない閉域網でAmazon Web Servies(AWS)に直接接続、秘匿性を保ったまま映像データを上げられるとしている。 アプリ画面。飛行経路・時間・機体選定の設定は … 続きを読む

クラウドベンダーの比較

はじめに

3大クラウドと呼ばれているAWS、GCP,Azureのリソースを比べてみました。
2017年11月時点の比較となります。

インフラ・サービスレベル

比較項目 AWS GCP Azure 備考
データセンター 各地で借りている すべて自前 各地で借りている(一部自前)
仮想化技術 Xen KVM Hyper-V
リージョン(国内) 1個所 1個所 2個所
リージョン(全国) 15個所 12個所 36個所
SLA 99.95 99.95 99.95 仮想サーバ

サービス面

比較項目 AWS GCP Azure 備考
仮想サーバ Amazon EC2 Google Compute Engine Azure Virtual Machines
仮想サーバ対応OS Amazon Linux,CentOS,RedHat,Windows Server,等 CentOS,RedHat,SLES,Windows Server,等 CentOS,RedHat,Windows Server,等
仮想サーバディスク SSD,HDD SSD,HDD SSD,HDD
仮想サーバスナップショット
仮想サーバオートスケール
コンテナ Amazon ECS Container Engine Container Service
RDB RDS Cloud SQL SQL Database
RDB冗長化
RDBリードレプリカ
RDB DB種別 Aurora,MySQL,MariaDB,Oracle,SQL Server,PostgreSQL MySQL,PostgreSQL SQL Server
NoSQL DynamoDB Cloud Datastore Cosmos DB
ビックデータ Redshift BigQuery App Service
メール Amazon SES
モニタリングツール CloudWatch Stackdriver Azure Monitor
ロードバランサー(L4) CLB Network load balancing Azure Load Barancer
ロードバランサー(L7) ALB HTTP load balancing Application Gateway
CDN Amazon CloudFront Google Cloud CDN Azure CDN
VPN Amazon VPC Google Cloud VPN VPN Gateway
DNS Route53 Google Cloud DNS Azure DNS
専用線 Direct connect Dedicated Interconnect Express Route

サポート面

比較項目 AWS GCP Azure 備考
ランク低 開発者 ($29/月 or 利用料の 3%/月) シルバー ($150/月) Standard($300/月)
ランク中 ビジネス($100/月 or 利用料 の10%/月) ゴールド($400/月) Professional Direct($1,000/月)
ランク高 エンタープライズ($15,000/月 or 利用料の10%) プラチナ(問合せ) Premier(問合せ)

費用面(リージョン日本)

比較項目 AWS GCP Azure 備考
課金単位
ディスカウント リザーブドインスタンス(前払い) 継続利用割引、利用確約の割引(前払い) エンタープライズ契約(前払い)
仮想サーバ(Type) t2.medium(2vCPU,4GB) n1-standard-2(2コア,7.5GB) A2 V2(2コア,4GB)
仮想サーバ(時) $0.0464(5.336円)※1 $0.0950(10.925円)※1 $0.15(17.25円)※1
仮想サーバ(月) $33.408(3841.92円)※1 $48.17(5539.55円)※1,※2 $108(12,420円)※1
インターネットへの転送量 $0.140/GB(10TBまで) $0.12/GB(1TBまで) $0.138/GB(5GB-10TB、5GBまでは無料)
ストレージ利用料 $0.025/GB (最初の50TB/月まで) ※S3 $0.016/GB 月 ※Regional Storage $0.2/GB(最初の50TB/月まで) ※BLOG Storage

※1 $1=115円換算
※2 継続利用割引含む

総括

 AWS、GCP,Azureでのサービス面では同じようなサービスを展開していることが判明。
 インフラ・サービスレベルでは、Azureがリージョン36個とTOPに。
世界的に見て幅を利かせているように思えた。
ただ、GCPはすべて自前のセンターでクラウドサービスを展開していることから、
新しいことをやるにも制約が低いように思えた。
私のイメージ的に一番シェアが高いAWSは、インフラ面ではGCP,Azureに劣っている結果となった。
 費用面では、Azureは割高。AWSが思ったよりも頑張っているように思えた。
 イメージ的にGCPは費用は安いと思っていたが、仮想サーバ比較だと、継続利用割引を使用してもAWSのほうが安い結果となった。
 ただ、費用に関しては、日々値下げ合戦が繰り広げられているので、今後のベンダーさんの努力に期待です。

最後に、費用面での算出に使用した見積もりツールです。
【AWS】http://calculator.s3.amazonaws.com/index.html
【GCP】https://cloud.google.com/products/calculator/?hl=ja
【Azure】https://azure.microsoft.com/ja-jp/pricing/calculator

続きを読む

VPC内に置いたElasticsearch ServiceにEC2のプロキシ経由でアクセスする

先日のアップデートでElasticsearch ServiceをVPC内で使えるようになりました。
https://aws.amazon.com/jp/blogs/news/amazon-elasticsearch-service-now-supports-vpc/

これまではパブリックなエンドポイントしか使えず、VPC内からアクセスするにはパブリックサブネットからの通信が必要でした。
VPC内に配置できれば、通信も全部VPC内で完結しますし、よりセキュアに使うことができるようになりますね。

さて、VPC内に配置したときに起きる問題の一つが、 直接ローカルからKibanaを見ることができない という問題です。
パブリックサブネットに配置してセキュリティグループで接続許可すれば行けるだろう、と最初は思ったんですが、どうやら無理みたいです。
※うまく行った、という方がいたらご教示ください…。

これを解決するためにどうするかについてはいろいろ調べてみました。
1. ALBを使う。
こちらを参考
https://dev.classmethod.jp/cloud/aws/make-public-kibana-amazon-es/
メリットは管理するサーバが増えないこと。
デメリットは、Elasticsearch ServiceのプライベートIPは可変なのに対し、ALBはターゲットにIPかEC2インスタンスしか設定できず、ターゲットのIPを定期更新するなどしなければならないこと。
1. EC2にKibanaをインストールして、Easticsearch Serviceを参照するようにする。
こちらを参考
https://dev.classmethod.jp/cloud/aws/make-public-kibana-amazon-es2/

メリットは、ドメイン指定が可能なのでElasticsearch ServiceのIPが変わっても大丈夫なことなど。 デメリットは、Kibanaの部分がEC2依存になること。
1. Windowsのインスタンスを立ててそこにリモートデスクトップでアクセスし、Windowsインスタンス内のブラウザからKibanaにアクセスする。
読んで字のごとくです。
メリットはやることが単純明快なことかな?
デメリットは大抵のケースで余計なEC2インスタンスを増やさざるを得ないこと。
1. EC2をプロキシサーバにする。(今回の方法)
EC2にKibanaを入れるパターンに近いですが、KibanaもElasticsearch Serviceのものを使用するので、Kibanaの可用性をElasticsearch Service(つまりAmazon側)に依存させたままにできるのがメリットです。
デメリットはこちらもアクセスがEC2依存になること。

今回は調べてもVPC内に配置したElasticsearch Serviceを参照するために使用したという例が見つからなかった、プロキシサーバを使う例について書いてみます。
※別の目的でプロキシサーバ経由にする例はたくさんありましたが、いずれも今回のアップデート以前の情報でした。
今回の例ではnginxを使用しますが、別にApacheでもなんでもいいと思います。

方法

パブリックサブネットにEC2インスタンスを用意する。

特に何も考えずにAmazon Linuxでよいと思います。
インスタンスタイプはとりあえずt2.microでもいいですが、
使ってるうちに負荷がしんどいなと思ったら適宜変更しましょう。
当然のことながら、SSHに加えhttpでアクセスできるようにセキュリティグループを設定します。
場合によっては踏み台サーバと共用とかでも大丈夫かなと。
※今回の例ではhttpを使用し、httpsではやらないようにします。
httpsを使用する例はこちら。(今回の設定もこちらを参考にしています。)
http://inokara.hateblo.jp/entry/2016/10/22/123538

用意したEC2からElasticsearch Serviceクラスタにアクセスできるようにする。

セキュリティグループの設定およびアクセスポリシーを適切に設定します。
セキュリティグループだけにしてもいいですし、リソースベース、IPベース、IAMユーザ・ロールベース等ポリシー設定できるのでその時の要件に沿って適切に設定すればOK。
http://docs.aws.amazon.com/ja_jp/elasticsearch-service/latest/developerguide/es-createupdatedomains.html#es-createdomain-configure-access-policies
余談ですが、Elasticserch Serviceの設定変更には意外と時間がかかるので、なるべく設定変更が少ないほうが気持ちが楽だと思います。

EC2インスタンスにnginxをインストールする。

深く考えずにyumでOKです。

sudo yum -y install nginx

/etc/nginx/nginx.confを編集する。

50行目付近に

nginx.confの一部
        include /etc/nginx/default.d/*.conf;
        location / {
        }

みたいに空で設定されているところがあるので、下記のようにします。
※抜粋、略記しています。

nginx.confの一部
        include /etc/nginx/default.d/*.conf;
        location / {
            proxy_pass https://xxxxxxxxxxxxxx.amazonaws.com/;
        }

といった感じに、proxy_pathでVPCエンドポイントを指定します。
httpsじゃなくてもいいみたいですが、httpsで問題なくアクセスできます。

nginxを起動する。

nginxのサービスを起動します。ついでに自動起動もONにしておきましょう。

sudo service nginx start
sudo chkconfig nginx on

これで
http://{{設定したインスタンスのパブリックIP}}/_plugin/kibana
にアクセスしてやれば、EC2を経由して該当のElasticsearch ClusterのKibanaにアクセスできます。

課題とかおまけとか

後ろに_plugin/kibanaをつけないでアクセスするとElasticsearchにもアクセスできちゃうので、それを良しとするかどうかは要検討です。
逆にローカルから手軽にデータ投入できたりもするわけですが…。どこまで許容するかですね。
そこを気にするのであれば、nginxの設定とかでディレクトリごとにアクセス制御するとかが必要かもしれません。

あと、Elasticsearch Serviceを配置したVPCにVPN接続している場合はこんなことしなくてもVPNエンドポイントを指定して直接参照できる気がするので、試した方いたらご教示くださると嬉しいです。

ALBでElasticsearch Serviceのインスタンスを指定できるようになればいいんですけどねえ。

続きを読む

AWS DMSでオンプレミス OracleSE1からRDS for OracleSE1移行時のハマったところなど

はじめに

現在弊社ではシステムを非AWS環境からAWSに移行する作業をしております

本記事は、AWS移行作業の一部であるDB移行を、AWS DMSで行った際に遭遇したつまずきポイントなどをまとめます

目次

  • DMS側のつまずきポイント

    • レプリケーションインスタンスのインスタンスクラス問題
    • 新機能のデータ検証使えない問題
    • インスタンスごとのエンドポイント設定数制限問題
  • ソースDB側のつまずきポイント
    • 社内セキュリティポリシーの問題
    • 1日たったら変更データキャプチャ (CDC) 動かなくなる問題
  • ターゲットDB側のつまずきポイント
    • 適切なRDSのスペック選定問題
    • データベースリンクの問題
    • ユーザー作成+シーケンスの問題

DMS側のつまずきポイント

レプリケーションインスタンスのインスタンスクラス問題

DMSを初めて触るに辺りお試しで移行しようと思い、ケチってレプリケーションインスタンスのインスタンスクラスをmicroで作ったのですが、これがまずかったです

microインスタンスだと100%エラーが発生し、タスクが失敗しました

設定自体は完璧なのにタスクが実行できず、以下のようなエラーログが出たら、インスタンスクラスをアップグレードすることをおすすめします

Task error notification received from subtask 0, thread 0 [XXXXXX] Oracle CDC maximum retry counter exceeded.
Task 'XXXXXXXXXXXXXXXXXXXXXXX' encountered a fatal error

新機能のデータ検証使えない問題

移行作業中にDMSの機能がアップグレードし、移行前のタスク評価移行後のデータ検証が使えるようになりましたので、早速データ検証を使ってみた所ハマりました

データ検証を使用するにはレプリケーションエンジンのバージョンを2.4.0(東京リージョンの場合)にする必要があります

レプリケーションエンジンの2.4.0バージョン情報は、本記事作成時点では公式マニュアルに記載されていませんでした

使うにはタスク設定画面の検証の有効化をONにすることで使えるようです

ただうちの環境でここをONにすると、そのタスクは100%失敗しました

CloudWatchのログには以下のように出てます

Cannot get special table's id for table awsdms_validation_failures

公式マニュアルによると、検証の有効化をONにするとターゲットDBに「awsdms_validation_failures」というテーブルを作るようです

このテーブルには診断情報を書き込むようで、検証エラーのトラブルシューティングに使えるようなのですが、このテーブルすら作られていませんでした

また、一度検証の有効化をONにすると、タスク編集でOFFにして再度タスク実行しようとしても、そのタスクは以降ずっと失敗するようになりました

公式記載の制限事項はクリアしていたかと思いますが、原因がわからなかったので、検証機能は使わないようにしました

インスタンスごとのエンドポイント設定数制限問題

DMSには結構作成リソースの制限が厳しいです

以下公式記載の東京リージョンでの制限値です

リソース デフォルトの制限
レプリケーションインスタンス 20
ストレージの合計 6TB
イベントサブスクリプション 100
レプリケーションサブネットグループ 20
レプリケーションサブネットグループあたりのサブネット 20
エンドポイント 100
タスク 200
インスタンスごとのエンドポイント 20

今回DB移行する対象のサービスは、DB4台のスキーマ数100以上でした

レプリケーションインスタンスは2台だったので、エンドポイントを作っては消し、作っては消し…を繰り返しました

後からレプリケーションインスタンスの数を増やすことが社内事情で難しかったため、もし大量の移行作業をする場合は、予めレプリケーションインスタンスを大量に作っておいたほうがいいでしょう

ソースDB側のつまずきポイント

社内セキュリティポリシーの問題

AWSに移行前の環境では、DBに関してのレコード操作以外の作業はすべてDBGという部署が管理していました

  • GIPを割り当てることNG
  • root権限使用NG
  • VPC環境外からのDB接続NG
  • スキーマ・ユーザー作成NG

制限だらけです

AWS外の環境からDMSを使って移行する場合、AWS Direct Connectや、VPN接続といった複数のオプションを使用して繋ぐ方法もありますが、GIPでの接続が一番簡単で安価です

また、DMSを使うための専用ユーザーを作る必要もあります

OracleをソースとしてDMSを使う場合は、ARCHIVELOGモードやサプリメンタルロギングをオンに設定する作業もありますし、ポリシーと相違する事だらけです

ここの対応をお願いする調整が大変でした

DBGに対応依頼をしても「無理です」の一点張りになりますので、一番偉い人に土下座してお願いするのが手っ取り早いです

1日たったら変更データキャプチャ (CDC) 動かなくなる問題

今回のDB移行作業は1つのタスクを1日以上実行しっぱなしにすることはないのですが、たまたま作業が日をまたいだ時がありました

出社してタスクの状況を見たらタスクが止まっており、何故かを調べた所1日1回DBのセッションをリフレッシュする処理が入ってました

この処理を止めることは社内ルールとしてできなかったため、「1日以上かかるタスクは作らない」という運用でカバー(魔法の言葉)しました

ターゲットDB側のつまずきポイント

適切なRDSのインスタンスクラス選定問題

旧環境ではかなり余裕を見たテーブルスペースサイズをそれぞれのスキーマーに割り当てており、正式な必要ディスク領域を算出することが難しかったです

単にDBのHDD使用量を見るだけではわからないということです

データベースリンクの問題

旧環境では一部スキーマにDatabase linkがLIPで設定されていました

当然RDSからは使えないのでここの修正が必要です

Database linkの問題はすぐに気が付かなかったので、検証・調査に結構時間がかかりました

ユーザー作成+シーケンスの問題

DMSはセカンダリインデックス、シーケンス、デフォルト値、ストアドプロシージャ、トリガー、シノニム、ビューなど、データ移行に特に関係ないスキーマオブジェクトは移行しません(公式マニュアル

また、ターゲットDBにスキーマを作成してくれません(公式マニュアル

なので一個一個のスキーマ、シーケンス等を作成するSQLを作り、RDS Oracleに作る作業が面倒でした


以上、色々つまずきましたがDMSのお陰で、4つのDB、100位上のスキーマの移行作業が、サービス停止すること無く1ヶ月で出来ました

DMSバンザイ!

続きを読む

俺が実現したMySQL 5.5 to Auroraマイグレーション

46億のmysqldump愛好家な皆様こんばんわ
ちょっとMySQLデータベースの移行経験ある俺です。ワタシチョットイコウデキル

ついに俺でもわかるシリーズタグの記事が30本目を迎えました。
俺以外の俺達も俺でもわかるシリーズタグをつけて記事書いてくれたこともあり、感謝の24365なエブリデイです。

記念にMySQL 5.5の環境からAuroraへダウンタイムを抑えて移行する方法を書き残します。
今回の例ではオンプレミス環境からAWSをターゲットとしていますが、AWS to AWSも可能です。

詳しく知りたい方は弊社の俺宛に連絡下さい。
ひょっこりノコノコ伺いに行くと思います。

過去Auroraへの移行を実現した手段

今回の構成

こんなかんじです。
データセンターとVPC間はインターネット接続なのでstunnelでトンネルはってます。
VPN Connection/Direct Connectでセキュア, 高速回線引いておいても良いです。

image.png

レプリケーションパターンでふつうに移行するとこんな流れになります

MySQL 5.5の環境をふつーにAuroraへ持っていく場合

事前準備

事前準備においてしんどいのは
MySQL 5.5 on EC2へのデータリストア, MySQL 5.6へのバージョンアップとAuroraへのリストアです。
移行対象のDBクラスタが多いほど辛みが増します。

事前複製作業

1.MySQL 5.5環境をターゲット環境に作る
2.ソース環境のMySQL 5.5からmysqldumpを使ってDBをバックアップする
3.バックアップしたDBデータをターゲットのMySQL 5.5環境へリストアする
4.ターゲット環境にAuroraを準備してバックアップしたDBデータをリストアする
5.ターゲット環境のMySQL 5.5をMySQL5.6へバージョンアップする

事前レプリケーション作業

6.ターゲット環境のAuroraとMySQL 5.6とレプリケーションする。
7.ターゲット環境のMySQL 5.5環境をMySQL 5.6にバージョンアップする
8.ターゲット環境のMySQL 5.6環境からソース環境のMySQL5.5にレプリはる
9.レプリケーションエラーなく同期できることをチェックする

切替当日

10.レプリケーションエラーの有無をチェックする
11.アプリをメンテに入れる
12.レプリケーションを止める
13.アプリエンドポイントを切り替える
14.裏口からアプリ動作チェック、データ整合性チェックする
15.アプリのメンテを解除する
16.ソース環境とターゲット環境のMySQLレプリケーションを停止して、環境を破棄する。
17.最高

MySQL 5.5からAuroraへの移行にDMSを使う

ちょっと楽するためにData Migration Service(DMS)を使います。
DMSを使った流れは以下の通りになります。

事前準備

DMSを使うことでAuroraへのデータリストアをすっ飛ばすことができますいえいいえい

事前複製作業

1.MySQL 5.5をターゲット環境に作る
2.ソース環境のMySQL 5.5からmysqldumpを使って移行対象のDBデータ(mysqldump dbname)とDDL(mysqldump –no-data)をバックアップする
3.バックアップしたDBデータをターゲットのMySQL 5.5環境へリストアする
4.ターゲット環境にAuroraを準備してbinlogを有効にする
5.バックアップしたDBのDDLをAuroraにリストアする

事前レプリケーション作業

6.ターゲット環境にDMSインスタンスを準備して以下の条件でDMSレプリケーションを実行します
ソース: ターゲット環境のMySQL 5.5
ターゲット: Aurora
レプリケーション方法: フルロード,フルロード後はCDC
※補足: DMSのソースDBをオンプレミス環境のMySQL5.5にすることも可能ですが、レプリケーション異常発生時の切り分けを、DMS依存のものなのか、オンプレミス<->VPCネットワーク障害なのか切り分けしやすくするため、EC2にMySQL5.5環境を作っています。

7.ターゲット環境のMySQL 5.5環境からソース環境のMySQL5.5にレプリはる
8.MySQLレプリケーション/DMSレプリケーション両方エラーなく同期が継続していることをチェックする

切替当日

9.レプリケーションエラーの有無をチェックする
10.アプリをメンテに入れる
11.DMSレプリケーションを止める
12.アプリエンドポイントを切り替える
13.裏口からアプリ動作チェック、データ整合性チェックする
14.アプリのメンテを解除する
15.ソース環境とターゲット環境のMySQLレプリケーションを停止して、環境を破棄する。
16.最ッッッ高ッッ!

DMS利用時の注意点

DMSにはいくつか制約があります。どんな制約があるかはここには書きません(DMSの機能も定期的に更新されていくので)

必ず移行計画時点でドキュメントをチェックし、移行対象の環境で制約があてはまらないことを確認してください。
当てはまる場合は回避できるように対応をしてください。

良い移行ライフを!

続きを読む