初心に帰ってAWSの良さを伝える練習をしてみた
ベルリンのしがひです。日曜日の昼下がり、CrowdWorksに4月25日締め切りで記事単価4000円の「AWSで何ができる?メリット・デメリットをわかりやすく解説・クラウドを導入するならAWSがおすすめな理由3つ」という急募案件がありましたので、初心に帰って2000字程度でAWSの良さを伝える文章を書いてみました。ご自由にお使いください。
AWSで何ができる?メリット・デメリットをわかりやすく解説 〜 クラウドを導入するならAWSがおすすめな理由3つ
昨今、ITプラットフォームの話題の中心は常にクラウドだと言っても過言ではありません。そのためクラウドを前提としないITでは変化のスピードに追いつくだけでも、情報収集、事例研究、検証、調達、実装、保守とあらゆる段階で困難になりつつあります。
しかし、個々の開発者やテスト環境のみならず、企業の本番環境システムでクラウドを使うことに相応のメリットはあるのでしょうか?本稿では、なぜクラウドを導入すべきか、またなぜ導入するならばAWSかを3つの理由をもとに解説します。
インフラ調達、構築、保守からの解放
ITのハードウェア、ネットワークといったインフラは、構成を計画、予算化、リースなどの資金管理、ベンダー選定、購入という調達業務があり、実際の構築には人手が必要なためプロジェクトマネージメントが必須です。さらにデータセンターなどの設置場所、ハードウェア保証、状態監視、修理と、複数のプレイヤーをまたいだ保守とライフサイクル管理が避けられません。またTCOを考える際、このような複数の部署のマネージメントコストは曖昧にされ、管理会計上のコスト検証を阻害します。
クラウドの最大のメリットは、インフラに関するプロセスの大幅な省力化とコストの明確化です。
SAP ERPの3システムランドスケープ(開発機・検証機・本番機)を例にとると、インフラをソフトウェアがインストールできるところまで完成させるために伝統的な手法では1ヶ月近い線表を引くことになります。AWSであれば同じようなシステムを実現するためのEC2、VPCの構成は数分で完了します。また同時に、保守を含めたコストはマネージメントコンソールで1分・1セント単位で可視化されます。
トライアンドエラーの許容と伸縮運用
プロセスが省力化されることは、失敗時の手戻りも短縮されることを意味します。
上記の例をとると、ハードウェアベンダーはユーザーや伝票数などの要件から予測されるSAPS値というベンチマークを使ってサイジングを行います。多くの場合大幅なリスクファクターを見積もるため、1千万円超えの資産が誕生してしまいます。また仮に処理能力が十分でなかった場合、インフラの見直しを嫌ってソフトウェア側の仕様変更を余儀なくされることも珍しくありません。
AWSの場合、インスタンスの伸縮は一瞬にして自在です。これは初期サイジングの最小化と、検証機段階での最適化を可能にします。またメンテナンスフェーズに入ったシステムでは、開発機の縮退運用が一般的に行われます。また多層アーキテクチャにおいて、各レイヤー毎のリソースを検証した上で的確な伸長が可能です。
このようなトライアンドエラーを前提としたインフラは、現代的なプロトタイピング開発において、当然備わっているべき要件と言えます。
可用性、安全性、監査可能性を高次元で実現
AWSはコンピューティングパワーに限定されない様々なアプローチでシステムを拡張できます。
ERPの例をさらに深掘りすると、完全に分離された環境(アベイラビリティゾーン)をまたいでインスタンスとネットワークを構成してActive - Activeの運用を行ったり、別の国、または地域(リージョン)にディザスタリカバリサイトを開設する事も容易です。ログやアーカイブに使用するオブジェクトストレージのS3は99.999999999%の耐久性を擁し、さらにプレゼンテーション層へのロードバランサの導入、OracleやMS SQLなどのデータベース層をマネージドサービス(RDS)へ移行してスケーラビリティと保守の省力化を狙うなど、従来では取りにくかった戦略の選択肢があります。
また、ISOをはじめとしたインフラ全体の認証と認定、暗号化、鍵管理、物理的セキュリティが利用開始時から備わっており、責任共有モデルを介して認証、設定内容、使用状況の監督が文書化され、GDPRをはじめとした昨今の厳しい監査可能性要件への対応を助けます。
これらをAWSなしで実現するには膨大なコストが必要で、現実的ではありません。
クラウドのメリットを享受するために
クラウドの導入にあたって、新たなノウハウが必要になる、ユースケースによってはオンプレミスよりも高いなど、デメリットが強調されるケースがいまだに散見されますが、上記のメリットを享受するためにはクラウドを前提としたシステムとビジネスの設計、評価サイクルが不可欠です。
クラウドで変わることと同じように、クラウドのために変わっていく必要もあるといえます。