Help us understand the problem. What is going on with this article?

パブリッククラウド推進の為に理解すべき3つの事

More than 1 year has passed since last update.

唐突ですが AWS、Azure、GCP等のパブリッククラウドに対して、適切な理解を進める為に、私が掲げる3項目を備忘録代わりに残しておきます。

1.利用するという考え方へのシフト

「クラウドに預ける、任せる」という考え方から脱却し、単に利用者がそれぞれのサービスを使うかどうかというドライな考え方をしましょう。
AWSやAzureは「任された」なんてこれっぽっちも思ってくれません。
彼等が提供しているのはただの標準サービスです。

標準サービスというのは、身近な所ではコインロッカーなんかがいい例です。
コインロッカーというサービスは、だいたい以下のような仕様で提供されているでしょう。

  • 施錠可能なスペースのレンタルサービス
  • サイズは 30cm~数メートル 四方まで様々
  • (主に)材質はスチール
  • (主に)鍵はディスクシリンダー錠
  • 設置されている場所は公共のスペースや私有地内である
  • 利用料は100-500円程度で明示されている
  • 連続使用は3日-1週間程度に制限されていて、明示されている
  • 管理者はマスターキーをもっている

このように仕様や料金が、一定且つ明確に提供されているサービスの総称が標準サービスだと理解ください。

こうした仕様を基に、利用者は「どのくらいの期間」「どの程度貴重なものを」預けるか検討します。
また、例えば「2番のスペースをピッキングに強いディンプルキーに変更してくれ...」等、要望を出すこともありませんね。
よほど大規模なケースでない限り、標準サービスに対してこのようなRFPを出すような事もないでしょうから、提供されているありのままを使う形で検討をスタートさせるでしょう。

AWSで言うところのEC2やS3も同じような標準サービスと捉えて下さい。

「AWSに○○を任せられるか、預けられるか」ではなく、「○○を構築するにあたって、EC2やS3が適しているか」という視点で議論を進めたほうが良いです。

そうする事で、オンプレシステム比でどういった点が懸念かが見えてくるでしょうし、懸念を払拭出来るのか、それともリスクを受容しなければいけないのか等、議論を前に進める事が出来るでしょう。

2.単純にコストが下がるという幻想からの脱却

必要最低限の稼働時間でインスタンス利用する等、しっかりとパブリッククラウドの料金体系にフィットさせる事が出来れば結果的にオンプレミス比でTCOを削減出来る可能性は高まります。
しかし、システム全体を単純に移行した場合、コストはむしろ上昇する傾向があります。

コストについての議論を進める場合にはこうした側面を正しく理解し、現状抱えている課題に対して、付加価値を以ってコスト比較をするアプローチが適切だと考えます。
例えばこのような比較をした場合は、ほぼ間違いなくAWSにコストメリットがあるでしょう。

  • BCPの観点からバックアップデータをリモートサイトへ転送したい
    • オンプレミスの場合:追加DCの契約やデータ転送のオペレーションによるコストを試算
    • AWSの場合:別リージョンのS3利用料、データ転送料、バッチジョブを実行する為のコストを試算

その他にもコスト削減につながりやすい代表的な仕組みとしては、AWSだと以下のようなものがあります。

 ・オンプレミスでは出来ない事(実現難易度が高い事)
  ・マネージド型サービスの利用
  ・ネットワーク、コンピューティングの迅速なデリバリー
  ・世界規模でのDR、BCP

 ・豊富なエコシステムの活用
  ・Cloudwatch利用
  ・ACMによるSSL証明書取得

移行初期では利用しないにしても、将来的にこれらのサービスを使う予定があるのならば、必要になったタイミングで余計なキャッシュアウト無く直ぐに利用可能だという付加価値に追加コストを払ってもいいんじゃないでしょうか。

3.セキュリティへの不安は明確に持つべし

「AmazonやMicrosoftやGoogleといった超大企業で超優秀な人間が揃いまくってる会社が開発し、運用しているインフラやアプリを使うのと、自社のオンプレミスを比較する意味がよく分からない。戦う相手にしてはでかすぎる。」
 ~ロードバランスすだちくんブログ からの引用~

痛快ですね、この方のブログエントリはタテマエとかが無いのでスッと入ってきます。
ご興味の有る方は最後にリンク貼りますので原文をどうぞ。

単純なアウトサイダー型攻撃に対するセキュリティという事だと、一企業レベルで構成可能なインフラを遥かに凌駕するレベルで考え抜かれている事はあえて言うまでもないですね。

しかし、セキュリティは結局の所自己責任です。
具体的なリスクをリストアップして、そのリスクに対して、EC2・EBS・ELB等ではどのように対策可能なのか、どういった部分にコントロールが必要なのかを「個別に解決」していく必要があります。

Gartner社は 「完璧なセキュリティ」 を目指すのではなく、ビジョンとして「レジリエンス (回復力)」を掲げ、まずは説明責任が果たせるレベルを目指すといいんじゃないかと言っています。
ここで定義されている「説明責任」とは「個別に解決」した上記のプロセスそのものですね。

第三者が運用するという事そのものに対して漠然とした懸念があるという事だと、SaaS型の Office365や、GMail等、同様の理由で採用を見送らなければいけないサービスが山のように出てきてしまいます。

まずは漠然とした不安を、「個別に解決」するプロセスを経て、明確化していく事が不安解消への近道です。

最後に

本稿の作成にあたり、参考にさせていただいた内容は以下の通りです。

Kedamari
法人向けISPのインフラSEを12年経験し、現在はAPNパートナーとしてAWSプリセールスSEをしています。 AWSソリューションアーキテクトProfessionalを2017年10月に取得しました。
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした