マイグレーションにまつわる課題を解消-クラウドへの移行を成功に導く秘訣

アマゾン ウェブ サービス(AWS)と、そのパートナーが、企業が持つ様々な課題の解決手法を事例に基づいて解説するセミナーシリーズ「AWS Partner Network、マイナビ セミナーシリーズ AWSの進化がもたらす新たな可能性 ～クラウドがビジネスの未来にあたえる4つのメリットとは～」。その第4回が2017年11月21日 東京新宿にて開催された。シリーズの最後を飾るテーマは「クラウドマイグレーション」。実際に、サーバーをクラウドに移行する際の事例をもとに、その解決策を探る4つのセッションが開催された。

本記事では、それぞれのセッションについて、内容を紹介する。

AWSが見る「日本のクラウド移行最新動向」

最初のセッションに登壇したのは、アマゾン ウェブ サービス ジャパン エコシステムソリューション部 パートナー・ソリューション・アーキテクト 諸岡賢司氏である。

クラウドは、ビジネスの世界はもちろん、個人のサービスにまで広がりを見せており、すでに一般的な言葉として浸透している。AWSにおいてもここ数年ユーザーは増え続け、今では日本でも10万以上の顧客が同社サービスを利用している。

現在では新たにシステムを構築する際に、ビジネスの俊敏性の向上、コスト削減、または、運用負荷の軽減を目的として、オンプレミスではなく、クラウドの活用を選択肢として考える場面が多くなってきた。そこで検討事項となるのは、オンプレミスで利用していた既存のシステムを、どのようにAWSに移行するかである。諸岡氏によると、クラウドへの移行には以下のようなフェーズによって進められることが多いそうだ。

1.戦略・分析フェーズ
既存システムの棚卸しが主な作業となるフェーズ。IT資産の管理はExcelなどの表計算ソフトを使って管理されているケースが多く、入力漏れなどもあるため、担当者が各部署を回って一つひとつチェックするなど、泥臭い作業が行われることもある。諸岡氏曰く「もっとも時間と手間がかかる」フェーズだ。AWSでは、AWS Application Discovery Service (既存システムのデータ収集サービス)を提供して、準備期間の短縮及び負荷の軽減を行っている。

2.設計・移行フェーズ
POC(概念実証)を行うフェーズ。1部署や1プロジェクトなど、小規模のシステムをテストケースとして移行して、工数や時間、コストなどを検証する。「すべてのシステムを一度にクラウドに移行するのは得策ではないので、POCを実施した上での移行をお勧めしています」(諸岡氏)　実際に移行する際には、VM Import や、Server Migration Service / Database Migration Serviceなどを活用して既存システムからの移行を行い、AWS Migration Hub で全体進捗管理を行うようにしている。また、大量データの移行には、物理ハードディスクを用いて移行を支援するサービスAWS Snowball も活用されている。

3.運用・改善フェーズ
プロジェクト計画書を作り、本格的に移行する。クラウドの場合、部分的に移行していくケースが多いため、運用しながら小さな改善を繰り返していくことになる。

「AWSには、このように数多くのサービスが提供されています。それだけでなく、サードパーティからも多種多様なサービスが提供されています。また、移行コンピテンシーを所有しているコンサルティングパートナーもいるので、何か問題があったとしても、それを補うための手法は必ず見つかります」と力説し、セッションを締めくくった。

餅は餅屋に「クラウド移行はCIerを活用しよう」

続いてのセッションに登壇したのは、クラスメソッド AWS事業部 シニアソリューションアーキテクト 大瀧隆太氏である。AWS プレミアコンサルティングパートナーである同社は、クラウドマイグレーションについても、移行コンピテンシーを所有するなど、豊富な実績を持っている。大瀧氏によると「AWSマイグレーションの案件は年間数十件あり、常に複数案件が同時進行している」とのことだ。

オンプレミスからクラウドへ移行する場合「既存のシステムをそのままクラウドに移行する(As-Is)」と「クラウドの特性に合わせてシステムを変更する(To-Be)」の2パターンが考えられる。一見すると、そのまま移行するAs-Isの方が楽で、クラウドに合わせるTo-Beの方が大変だと考えがちだが、実際にやってみるとそうとも限らない。実は、As-Isの移行にはいくつかの落とし穴がある。

例えば、システムの構成やアプリケーションの推奨スペックを基準にコスト計算をすると、AWSが割高になることがある。コストを計算する場合、クラウドが持つ最大の特徴である柔軟性を考慮しなくては、適切な比較検討ができない。加えて、クラウドを柔軟に運用しようとすると、システムの構成も常に変化することになる。構成の管理もExcelなどを用いた手入力では追いつかない。

「AWSのリソースは可変です。オートスケーリングで毎日のようにインスタンスが入れかわることもあり、手入力で管理するのは非現実的です。AWSには構成管理をサポートするサービスがあるので、そちらを活用すべきです」と大瀧氏は力説する。そしてもう一つ、気を配るべき点としてあげたのが「ツールありき」の移行である。

「AWSには移行ツールも用意されていますが、その全てが移行できなかった場合も想定して、その回避策を検討しておくべきです」(大瀧氏)

一方、To-Beの移行についてはどうなのか。大瀧氏は「To-Beタイプの移行は最適化の積み重ねです」と解説する。もちろん、To-Beタイプは一から作り上げるものもあるので、それなりの苦労はある。ただ、クラウドに合わせて構築するものなので、As-Isで起こりうる事象については心配がなくなる。

As-Isタイプも、To-Beタイプも、それぞれに苦労はある。そして、スムーズに移行を成功させるためには「クラウドの専門家であるCIerを活用ください」と大瀧氏は語る。CIer (クラウドインテグレーター)は既存のSIerと対をなすものではなく、むしろ互いに苦手な部分を補って、よりよいシステムを生み出すために協力し合う関係だ。

「SIerさんは、AWSが良いということは知っていても、具体的なサービスや、運用に必要なことについてはあまり詳しくない場合があります。一方、我々のようなCIerは、SIerさんが手がけられているような大規模な案件については、人的リソースが十分用意できないことがあります。両方が互いに不足している部分を補い合っていけば、そこに最適解を見つけられるはずです」と語り、大瀧氏はセッションを締めくくった。

AWS移行時に押さえておくべきポイント

3番目のセッションでは、サイオステクノロジー 黒田将貴氏による、AWSへのマイグレーション時で「よく聞く話」と、それを解決するものとして「AWS Well Architected Framework」についての解説が行われた。

マイグレーション前によく聞く話には、「セキュリティが担保できるか」「安定したシステム運営が可能か」「既存の業務プロセスに影響は出ないか」などである。またマイグレーション後によく聞く話としては、「誰が何を作り、何を削除したのかがわからない」「AWSのサービスを活用できていない」などがある。

これらの話が発生する理由として、黒田氏は「マイグレーション前は、クラウドを知らないための不安であり、マイグレーション後についてはクラウドにあった形でのマイグレーションができていないことが問題」と解説。そして、このような話にならないようなマイグレーションの手段としてAWS Well Architected Frameworkの活用を提案する。

AWS Well Architected Frameworkは、「AWS上で、サービスをどう組み合わせ、どう設計すればよいか」を導くためのフレームワークで、「安定かつ効率的なシステムに必要な5つの柱」と「システムがAWSの特性を最大限活かすための設計原則(ベストプラクティス)」、そして「設計原則を適用できているか評価するための質問集」によって構成される。

この設計原則に従ってシステムを設計すれば、AWSのメリットを最大限に活かすことができ、結果として導入前によく聞く不安や導入後によく聞く課題についても解決できる可能性が高まることになる。

AWS Well Architected Frameworkが持つ「安定かつ効率的なシステムに必要な5つの柱」、それは「セキュリティ」「信頼性」「パフォーマンス効果」「コスト最適化」「運用性」となっている。今回のセッションでは、特に「信頼性」と「運用性」をフォーカスして解説が行われた。

最後に黒田氏はAWS Well Architected Frameworkにおける「信頼性」と「運用性」をサポートするサイオステクノロジーの商品としてAWS EC上のサービスの監視・自動復旧などを行う「SIOS Coati」を紹介し、セッションを締めくくった。

AWSへの全面移行を成功させたゴルフダイジェスト・オンラインの挑戦

最後に登壇したのは、2017年4月にAWSへの全面移行を実行したゴルフダイジェスト・オンライン シニアプロジェクトマネージャー 清水正朗氏だ。

ゴルフダイジェスト・オンライン(GDO)は、会員数320万人、月刊PV1.1億を誇るポータルサイトである。同社では、2009年からシステムを全面的に仮想環境へと移行。そのシステムについて清水氏は「大きな問題もなく、9年位にわたりGDOを支えてくれました。当初は社内でもいろいろな意見がありましたが、仮想環境への移行は正しい選択でした」と高く評価していた。だが、この仮想環境を支えていた製品のサポートが2017年秋に終了することとなり、AWSへの全面移行を検討することになった。

「当初は、AWSとオンプレミスのハイブリッドも考えましたが、新しいサービスの開始や終了にも柔軟に対応できるような、身軽で機動性のあるシステムにしたかったのです」と清水氏は当時を振り返る。

現在では、全体の約99%がAWSへ移行済みとのこと。移行に際してもっとも時間をかけたものが「移行のテスト」だそうだ。

「とにかく短期間で通常運用に持って行きたかったので、擬似本番環境上でテストを徹底的に行いました」(清水氏)

GDOのAWSへの移行は2017年2月22日の22時に移行が開始され、わずか8時間後の翌朝6時には完了した。そして、移行後は「クリティカルと呼べるトラブルはゼロ、障害もほとんどなく利用者に影響を与えるレベルのものは皆無」とのことである。

「これから時代はサーバーレスに向かうと思います。社内にサーバーを置いて、24時間365日監視する必要がなくなるかも知れないと考えています。もちろん、監視が必要なものもあるかとは思いますが、システムがダウンしたとしても、その際の設定をAWS側にしておき、翌朝に出社してから対処すればいい。そういう設計がAWSにはできるので、それぞれの運用にあった設定をすればいいのです」

清水氏は「これからも、いろんなサービスを展開して行きたい」との考えを示す。「それは、なるべくクラウドネイティブで、クラウドらしい使いかたをしていきたい。それで新しいことにチャレンジできればいいと思っています」

[PR]提供：クラスメソッド、サイオステクノロジー、アマゾン ウェブ サービス ジャパン