大規模データ移行の失敗を防ぎたい。計画やプログラム、インフラの注意点と、ありがちなこと - Qiita
仕事柄、大規模なデータ移行を何度か経験してきました。 データ移行、特にDBのマイグレーションでもなく、 システム移行のときのようなデータ構造の変更を伴う際には気をつけることがたくさんあります。 クラウドではだいぶ楽になりますが、 特にオンプレミスで検討せざるを得ない皆さんに気をつけないといけない点を共有します。 スケジューリング編 最初から検討し始めよう 開発プロジェクトにおいてシステム移行だけで4割の工数がかかると言われています。 しかし、新規システム部分の開発で頭が一杯になっていると、重要度の割に移行部分が後回しにされがちです。 移行用プログラム、移行用サーバ手配はもちろん、新規、既存システムへの影響も検討しないといけません。 できればプロジェクト開始時から人をアサインして計画を立てていきましょう。 移行自体が一つの開発プロジェクト相当です。頑張りましょう。 後半になって移行計画を立て
BINDからRoute53へ移設した際にやったこと
先日、とあるサービスで自前運用していたDNSサーバーをAWSのRoute53へ移設しました。 その移設の際に学んだ下記二点について、大変良い勉強になったので、折角なのでまとめておきます。 BINDからRoute53への移設方法 DNSのNSレコード移設時のポイント 移設前の環境 移設前のサーバーは他社のマネージドタイプの専用サーバーを契約しており、CentOS5のBINDで稼働していました。 DNSのセカンダリーには、そのマネージドサービスの無料のセカンダリーDNSサービスを利用しており、管理はマスターのみ実施しておりました。 移設が必要なゾーンは１つ。レコードが5000程度ありました。 また、ユーザーさんから申し込みがあった際に、BINDの動的更新を利用してレコードの追加が行われていました。 移設に至った経緯 大きくはCentOS5がEOLになったこと、BINDの脆弱性が多く、DNSの運
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
