ビヨンドでのマイグレーションとマルチクラウドの運用

ビヨンドでのマイグレーションとマルチクラウドの運用 株式会社ビヨンド

自己紹介 🞆 岡崎 潤一郎 🞆 システムソリューション部 係長 構築チームリーダー 🞆 運用から構築、移設までを幅広く実施 🞆 MSPJマイグレーションコンペ2連覇

会社概要①

会社概要②

アジェンダ インフラ視点のマイグレーション マルチクラウドの運用

インフラ視点のマイグレーション マイグレーションに関してインフラ作業は以下のようなものとなります。 インフラ部分については弊社で基本的に対応させていただき、アプリケーション側の検証に注力頂いております！ 調査 設計 構築 検証 ネットワーク構成調査 移行先ネットワーク 利用サービス設計 最小環境構築 ミドルウェア設定修正 スペック調査 移行先スペック設計 移行データ投入 スペック修正 OS・ミドルウェア調査 移行データ確認 検証用DB構築 ディレクトリ構成調査 移行先OS・ミドルウェア 設計 スケジュール作成 本番移行 運用 移行データ再投入 負荷状況確認 アラート確認 スケールアウト

調査・設計 ❏ 移設と同時にミドルウェアのバージョンアップをしたい、という場合も 多いので、この時点でOS, ミドルウェアレベルで障害になりそうな点を 調査 ❏ 調査内容に基づき移設先の構成やスペック移設するデータを確定 ❏ 移行全体のスケジュールを作成 現行インスタンス情報一覧 マイグレーション案件全体の骨格となる作業 ここでまとめた情報を元に移行作業を進める！ スケジュール案 移行先サーバ構成図 PJ側に共有

構築 🞆 設計内容を元に移設先環境を構築 🞆 設計時点で確定したデータを移設先環境に投入 🞆 データ移行にかかった時間を記録し、最大でどれだけかかるかを確認 🞆 DBデータについては当日作業を減らすためにレプリケーションなどで同 期を実施 サーバ起動 DB・コンテンツ移行 ミドルウェアインストール・設定 移行当日作業検証 最小構成構築 DBデータ同期 インフラ担当として最も手を動かす工程 前工程の設計でどれだけ詳細に調査・設計 出来ていたかで本工程がスムーズに行くかが 決まる

検証 ❏ ❏ ❏ ❏ 構築した最小構成環境で動作確認実施 OS、ミドルウェアレベルで問題が見つかれば都度修正 DBの更新確認が必要な場合は別途確認用にDBを起動 最小構成での検証が問題なければ本番台数へのスケールアウト OS・ミドルウェア設定修正 アプリケーション側動作確認 修正依頼 検証用DB作成起動 スケールアウト

本番移設 🞆 移設先環境へDNSを切替 🞆 必要があれば更新データを投入 🞆 最終動作確認を行い問題なければ移設先環境で動作開始 DBデータ同期停止 負荷状況監視 追加データ投入 アプリ側でメンテナンスを入れていただき 差分が無いようにデータ投入や同期解除を実施 また、アプリケーションの動作確認や移行後の負荷状況監視 問題なく安定するまで監視・対応継続

アジェンダ インフラ視点のマイグレーション マルチクラウドの運用

マルチクラウド運用実績 現状10以上のクラウド基盤を運用中 一極集中型というわけではなく ある程度バラバラに各クラウドを 運用中

マルチクラウドの運用 クラウド基盤ごとにサービスの提供状況も違うため、できることも変わってくる その上で最適な方法を提案することを考えて運用する ・A社 IP許可はサーバ単位できるがブロックはネットワ ーク単位でしかできないのでネットワークからブ ロックするもしくはサーバ側でのブロック DOS攻撃など特定IPブロック依頼 ・M社 IP許可/拒否をサブネット単位及び サーバ単位で対応可能

マルチクラウドの運用 クラウドごと障害リスクをマルチクラウドで分散することはでき、実際にリスクを低減することは可 能です。 ただクラウドごとのサービスの理解あること及び、アプリの挙動を把握していないとアプリ側の 影響範囲がわからなくなってしまいます A社クラウド DBサービス LBサービス VMサービス cacheサービス 例えばcacheサービスに 影響が発生したとしてそ のサービスを利用してい なければ影響はない

マルチクラウドの運用 クラウドでサービスが増えたとき、新しいクラウド基盤の運用が始まるときは 根本として各ミドルウェアやもととなるものの延長と考えてその上で何が出来て何ができない ？の部分を自分の知っている知識に置き換えて考えている DBサービス MySQLなどが動作しているVM サーバログインはできるのか？ DB自体へのログインはできるのか？ パラメータセッティングはどこまでできるのか？ バージョンはどこまで対応しているのか？ DBdump/importはできるのか？ etc …