S先輩にきいてみたっ！- Amazon Web Serviceのクラウド移行およびハイブリッドなアーキテクチャ - 第10話 高揚

S先輩にきいてみたっ！シリーズ、今回でとうとう最終回です。

今までの連載をご覧になっていない方は、ぜひご覧下さい。
[第１話](http://qiita.com/ukiuni@github/items/c82cf2b0b3d16ab7c2a0)
[第２話](http://qiita.com/kazuqqfp/items/1e326e1452468c33800b)
[第３話](http://qiita.com/imafuku/items/b40a5a9b049c38fdbd48)
[第４話](http://qiita.com/aikawa2002/items/191d34b5b7c2c836a69f)
[第５話](http://qiita.com/alingogo/items/d3b4b0e61791555d28f0)
[第６話](http://qiita.com/kenszk/items/3942f55fae098c4840ed)
[第７話](http://qiita.com/chano2/items/e261c73e09f0cbd8667e)
[第８話](http://qiita.com/saber_chica/items/fb283b78cc52dcc4e12b)
[第９話](http://qiita.com/imafuku/items/fae468d532fe10921b7e)

最終回のテーマは「クラウド移行およびハイブリッドなアーキテクチャ」です。
なお、ストーリーはフィクションであり、実在の人物・団体とは一切関係ありません。

# 第10話 高揚

「S先輩の結婚じゃなかったかー！」

自分の部屋に帰ってくるなり、Aは叫んだ。
S先輩が結婚するわけではないことがわかって、Aの気分はとても晴れやかだ。

「今日もAWSだ！」
昨日とは打って変わって、軽快にキーボードを叩き始めた。

いつも見ている「AWS 認定ソリューションアーキテクト – プロフェッショナル」の試験の分野を確認する。

「お、分野としてはもう最後なのか」

最後の分野は「クラウド移行およびハイブリッドなアーキテクチャ」。

「ふむふむ。今までAWSについてたくさん学んできたけど、移行の方法について学ぶことができたら、よりAWS活用の提案をするチャンスが増えるな。」

「いっそ、社内システムを全部AWSに移行してやるか。AWSに移行してやることで運用のコストがかなり減らせるはず。会社をハッピーにしてやれるぞ」

気分が晴れやかになり、考え方もとても積極的になっている。

「移行の具体例から調べてみるか」

すると、AWSの公式ページに「Windows Server 社内業務アプリ環境移行のためのクラウド構成例」というのが見つかった。
https://aws.amazon.com/jp/cdp/windows-bizapp-migration/

上記の例では、社内業務アプリ（Webサーバー + DB）をAWSに移行している。
AWSに移行することによって、以下のメリットが享受できる。

- Webサーバーのバックアップを簡単に取ることができるようになる
- RDSによりDBの運用管理負荷を軽減する

また、仮想専用ネットワーク（VPN）を使うことで、社内ネットワークから安全にクラウドを利用できることがわかった。

「お、まさにこのあたりの話しは社内システムをAWSに移行するときに使える話しだな」

続いて、移行のために具体的にAWSから提供されているサービスについて調べてみる。
AWSからはデータを移行するためのサービスが提供されている。

- Direct Connect
    - 専用のネットワーク接続を確立することで、ネットワーク転送の速度を上げる
- Import/Export Snowball
    - セキュアなペタバイト規模のデータ転送ソリューション
    - 大量データを簡単、高速、安全に転送でき、コストも安価に済む
- Amazon S3 Transfer Acceleration
    - Amazon S3 へのパブリックインターネット経由の転送をより高速にできる
    - メディアのアップロード、バックアップ、ローカルデータの処理タスクなど、世界各地から中央の拠点に定期的に転送される定期的なジョブに適している
- AWS Data Pipeline
    - データの移行と変換を自動化するためのサービス
    - データ変換を定義すると、指定された間隔で設定したロジックにしたがってデータ移行や変換が行われる

「いろいろあるな。やっぱりAWSの利用者を増やすためにもデータ移行の手段には力を入れてるんだろうな。」

移行に関して引き続き調べていると、AWS Database Migration Serviceというのを見つけた。
どうやら、データベースをAWSに移行するためのサービスで2016年の3月にリリースされたばかりの新しいサービスらしい。

「お、出たばっかのサービスだったら、もしかしたらS先輩もあまり知らないんじゃないか？」

S先輩が興味津々で話しを聞いてくれることを妄想しながら、AWS Database Migration Serviceについては特に詳しく調べた。

AWS Database Migration Serviceは、既存のデータベースをダウンタイムなしでAWSに移行するためのサービスである。
同種のデータベースを移行するだけでなく、異種データベース間の移行もサポートされている。

「へー、OracleのデータベースをAuroraに移行するなんてこともできるんだ」

データの移行中も既存のデータベースは通常通りに利用することができ、
データ移行中に発生した変更も、移行先のデータベースに反映される。

「移行中も既存のデータベースが利用できるのであれば、移行に取り組みやすいな」

また、Database Migration Service は高い障害耐性および自己修復性を備えている。
レプリケーションはモニタリングされ、例えば、移行が中断された場合には、プロセスが自動的に再起動され、停止した場所から移行が続行される。

「ほー、これはDB移行には必須のサービスだな。社内システムの移行にも使えそうだ」

ここまで調べて、A君は「AWS 認定ソリューションアーキテクト – プロフェッショナル」の試験の最後の分野に関して学ぶことに満足した。

S先輩と食事に行っていたこともあり、いつも以上に遅い時間になっていた。

「そろそろ寝るか」

ベットに入る。

が、S先輩のことを考えてしまって全然寝れない。。。

「S先輩が結婚するわけじゃなくて良かったな...」
「でもモテるんだろうな...」
「やっぱ彼氏はいるのかな...」
「S先輩が結婚するわけじゃないことがわかって、すごい安心したな...」

「うじうじ考えていてもダメだ！！行動を起こさなきゃ！！明日デートに誘うぞ！！」
考えが巡り巡って、深夜のテンションなこともあり、昨日までは考えもしていなかったところに終着した。

デートに誘うことを決意するといっそう眠れなくなった。。。

「どこに誘うのが良いかな...」

結局一睡もできないまま朝を迎えてしまった。

「おはようございます」
AWSの話しがしたいふうを装ってS先輩の席に行った。

「おはよう。いつにも増して眠そうね」

「昨日もAWSの勉強に夢中になっちゃって、全然寝る時間なくて、、、」
まさか、別の理由で寝れなかったとは言えない。

「昨日はAWSの『クラウド移行およびハイブリッドなアーキテクチャ』に関して学んできました！学んだこと聞いてくれませんか？」

いきなりデートに誘うこともできないので、AWSの話しをした。

「へー、Database Migration Serviceは知らなかったわ。DB移行には必須のサービスになりそうね。」

（おぉ、力を入れて学んで良かった！）

「とても勉強になったわ。学んだことを共有してくれてありがとう。AWSはどんどん新しいサービスが出るから、私もA君を見習って学び続けないとね」

「そんな、そんな！S先輩はいつでも新しい情報キャッチアップしてるじゃないですか」

（おぉー！！いつになく褒められてる！いつもなら「50点ね」とか言われるのに。）

「ただ、『クラウド移行およびハイブリッドなアーキテクチャ』として学ぶ内容としては少し足りてないわね」

（...）

「明らかに「ハイブリッドなアーキテクチャ」に関して全く触れてないじゃない」

（...）

「移行に関しても、ただ移行に関する技術を知るだけでなく、移行の方針を決めて、移行の計画が立てられることが必要よ」

「なるほど、、、」

S先輩は、移行の検討とハイブリッドなアーキテクチャに関して教えてくれた。

AWSへの移行を検討する場合、以下を考えるべきである

1. 移行方針
2. 移行方式
3. 移行方法

「A君が昨日学んだのは、3の「移行方法」ね」

「なるほど、確かに一部ですね」

「移行方針」で決めるべきは以下になる。

- どういう区切りで移行するのか
- どのアプリケーション、システムを移行するのか
- どのアプリケーション、システムから移行するのか

「すべてのアプリケーション、システムを移行するわけではない場合、
もしくは、順々にAWSヘの移行を行う場合には、
オンプレミスとAWSの併用、つまりハイブリッドなアーキテクチャを構築する必要があるわ」

上記を考えるにあたっては以下の評価を行うと良い。

- アプリケーション・ポートフォリオ管理による評価
    - アプリケーションのドメインや分類から、クラウドに適しているかどうかを評価する
- アプリケーション影響度による評価
    - 影響度の観点から、クラウドに移行しやすいもの、しにくいものを評価する
- システムのリース切れ/保守切れ/更改時期
    - システムのライフサイクルから、クラウド移行のタイミング、順番を評価する
- クラウド移行制約評価
    - AWSへの移行が可能かどうか評価する

続いて、2の「移行方式」。

「ここでも考えなきゃいけないことがたくさんあるのだけど、
そのうちの1つが移行パターンよ」

移行パターンには以下のものがある。

-  移行せずにシステムを撤去/廃棄
-  移行せずにオンプレミスに維持
-  アプリに改修を加えずにそのまま移行
-  アプリ仕様は維持し、一部マネージドサービスを利用
-  既存のアプリ仕様をベースに機能追加/改修
-  アプリを書き換え、マネージドサービスを活用
-  既存のアプリをマネージドサービスに置き換え

「なるほど、なるほど、確かに簡単に「移行」って言いますけど、
そのまま移すのか、マネージドサービスに乗せるのか、など
考えるべきことはたくさんありますね！」

「そうね。だから単にAWSの各サービスについて知ってる、というだけでやれることではないわね」

「んー、まだまだ勉強すべきことはたくさんありますね」

「そうよ、継続して一緒に頑張りましょうよ」

（まずいそろそろ始業時間になる、、、！）

「今日もいろいろ教えて頂きありがとうございました！
そういえば、、、」

（頑張れおれ！）

「何？」

「来週の土曜日って空いてますか？よかったら一緒に花火見に行きませんか？」

（言ってしまった、、、！！）

「花火？」

（急過ぎたかな。。。）

「いいわね！私行きたかったの」
S先輩は笑顔で答えた。

「いいんですか！！やったーーー！！！！」

S先輩が結婚するわけではないとわかった時の、何十倍も気分が高揚した。
今日の夜も眠れなそうだ。

「どうせ眠れないんだ、今日S先輩に聞いた話しに関していろいろと調べてみよう」
ニヤニヤしながら、独り言を言いながらA君は自席に戻った。
***
今回の話しで「S先輩にきいてみたっ！」のシリーズは終わりです。
いかがでしたでしょうか？
機会がありましたら、さらにA君が成長する姿を描きたいと思います。
第10話まで読んでいただき、ありがとうございました。