クラウド移行の構築作業フェーズでよくあるミスとその対処法：はじめてのクラウド導入“これ“に注意（1/2 ページ）
クラウド移行中の構築作業フェーズに焦点を当てて、よくあるミスとその対処法を解説する。クラウドの性能を引き出すためにも、このフェーズでのミスは避けたいところだ。
はじめてのクラウド導入では、多くの"あるあるミス"が起きる。連載第3回となる本稿は「構築作業」フェーズでのミスとその回避策を解説する。
はじめてのクラウド導入でよく起きる間違いを紹介し、どのように回避すべきかを紹介する本連載。第1回では「導入検討フェーズ」について、第2回では「移行作業フェーズ」に焦点を当てて解説した。第3回となる本稿は、いよいよ「構築作業」に着手する。このフェーズで気を付けなければならないポイントはどのようなものだろうか。
この連載について
本連載では、「Amazon Web Services」（以下、AWS）のようなIaaS・PaaSベースのパブリッククラウドサービスを導入するにあたって、「ありがちな誤解」や「つまずきポイント」とその「解決策」を、計画フェーズと移行フェーズに分けて解説する。クラウド導入検討の参考になれば幸いだ。
構築フェーズの大前提「クラウドは失敗しながら構築できる」
まず大前提として、クラウド移行はクラウドそのものの柔軟性で失敗を最小限にできる。
クラウドを利用する上で、ベースとなる設備や物理基盤、ネットワークはあらかじめベンダー側が用意しており、ユーザーはリソースの追加や変更を数分程度で実行可能だ。つまり、大まかなサイジングでシステムを起動し、動作をモニタリングしながらリソースを最適化できる。
もちろん、不要なリソースを簡単に止めたり捨てたりできる。また、設計パターンのテンプレート化やカタログ化の仕組みを活用すれば、構成済みの設計の再利用や修正がしやすく、PoC（概念実証）のハードルを下げ、設計からリリースまでの迅速性が増す。
構築計画が最初から100点満点でなくともプロジェクトに着手できることから、クラウドは「ビジネスクリティカルな基幹システムを本番稼働させる前に課題をあらかた出し切る作業ができる環境」といえる。
アーキテクチャを構築する際のコツ
クラウドがいくら柔軟でも、企業にとって設計や構築の目安となるガイドラインは重要だ。「Amazon Web Services」（以下、AWS）の場合は「Well-architected Flamework」（通称：ウェルアーキ）と呼ばれる、「望ましい設計や構築のためのベストプラクティスと指針」を公開している。
第2回で紹介した移行シナリオの「リホスト」ならば、オンプレミスでのシステム構成をそのままクラウドに移行でき、比較的設計方針が立てやすい。また、新規プロジェクトや新しいアーキテクチャに取り組む際は、上記のガイドラインを活用することで取り組みのハードルを下げられる。
見落としがちな、リージョンとサービスの問題
実際に構築の各ステップでつまづきがちなポイントについて、AWSを例に紹介する。
AWSでは、リージョンと呼ばれるデータセンタ群をどこにするかを利用開始時に選ぶ。本稿執筆時点でAWSのリージョンは世界31のロケーションで稼働しており、日本では東京と大阪から選べる。
国によってはリージョンが1つあるいは自国内にはなく、近隣国に存在するケースもある。リージョン選びではユーザーからの近接性が重要な考慮点だが、リージョンの所在地が海外になる場合は「データ保護に関する適用法がどう異なっているか」「それが自社のコンプライアンスポリシーにどう関係するか」などに注意を払う必要がある。
また、利用できるサービスや価格もリージョンによって差があり、基本的には後発のリージョンほどサービスラインアップが少なく、かつ価格が高くなる。つまり「災害対策のバックアップサイトに指定したリージョンで特定のサービスが利用できるかどうか」「想定よりコストがかかるかどうか」も確認しておこう。
Copyright © ITmedia, Inc. All Rights Reserved.