AWSを自社導入するなら押さえておきたい!非IT部門が主導するクラウド活用の進め方【後篇】

cover2

AWSクラウドを自社導入する際の進め方を前/後半に分けて紹介しています。今回は後半です!

前回の要点としては『まずは「独立したシステム」としてスタートする』と『全社公認化に向けガイドラインを整備する』をお伝えしました。今回はさらに引き続きさらに2点、事業部門(非IT部門)の担当者様向けにAWS導入の勘所をお伝えしたいと思います。

この記事の著者:江口 智
ITインフラコンサルタント。Amazon Web Servicesの導入コンサルティングや運用支援など、クラウドを軸としたITインフラ構築支援を得意とする。

AWSのスピード感を活かした体制を検討する

続いてはAWSの全社標準インフラ化にあたり「体制」を検討する際のお話です。特にAWSを社内システムと連携する場合「IT部門」との体制づくりが重要になってきますが、ここの設計でひとつ重要なポイントがあります。

それは「AWSのスピード感を活かした体制」を検討すること。

ひとつの例として、筆者がとある企業の宣伝部のAWS導入を支援したケース(仮にA社とします)をご紹介したいと思います。

A社では、自社プロダクトの販売促進やプロモーションサイトの運営を同社の宣伝部が広告代理店と共同で行っており、AWSシステムのオペレーションは代理店のパートナーであるWeb制作会社が一手に請け負っていました。そして、AWS公認化(社内システムとの連携)前後で次のように体制が変化しました。

AWS公認化前後における体制の変化
structure-large

 

さて、ここで重要になってくるのが「宣伝部(代理店、Web制作会社を含む)」と「情報システム部」の役割分担です。

もしAWSの利用にあたり、宣伝部から情報システム部への申請フローを厳格に管理し過ぎれば、「まずはトライ!」というクラウドの恩恵を受けられなくなってしまいますし、また宣伝部の権限を過剰に制限してしまった場合にも(例えば、サーバーの再起動のために申請が必要になる等)申請作業が煩雑化し、やはりAWSの持ち味を活かし切れないという結果に至ります。

スピードとセキュリティはトレードオフの関係にあり、つまりは落としどころを見極めるかたちになりますが、ここをうまくやりくりしないと、結果アンダーグラウンドなAWSが残存し、標準化が頓挫する事態になりかねません。

ここはお互いの業務特性を理解し合い(宣伝部:スピード/情報システム部:サービスの安定提供・セキュリティ確保)&粘り強く調整いただく他無いのですが、様々なAWS導入を経験してきた筆者としては、例えば以下のような役割分担をお勧めできればと考えています。

キャプチャ

 

ユーザーやアクセス権といったセキュリティ関連機能の管理、および物理ネットワークトポロジやIPアドレスなどのネットワーク構成管理は、社内システムとの連携の兼ね合いもあるためIT部門に担当いただくのがベストです。一方サーバーの電源ON/OFFやウェブ/アプリケーションサーバーの再起動といった細かな操作は、事業部門および外部パートナーで完結してしまうのが、サービスをスマートに運営する上でのコツといって良いでしょう。

すべてが理想どおりに進むほどサービス運営は簡単ではありませんが、まずは上記を念頭に検討されてみてはいかがでしょうか!

部門ごとのサービス使用量を把握する(課金管理)

さて、当水準までAWSを社内に浸透させるだけでも相当タフな作業ですが、この先起こる出来事についても触れておきたいと思います。ここからは事業部門の担当者様というより、全社標準インフラ運営を担当することになったIT部門管理者様向けのトピックです。

これまで一部門の利用に止まっていたAWSですが、今後は全社からの申請に応じてサーバー資源を割り当ててゆきます。こうした場合に課題となってくるのが費用負担配分の算出方法です。各部署がいつ・どれだけのコンピューターリソースを消費したのか、全社標準インフラを公正に運営していくにはこの根拠を必ず把握しておかなければなりません。

部署ごとのAWSの費用配分は、何を根拠に決定すれば良いのか?
charging

 

その際まず思いつくのは「アマゾン社からの請求書ベースで処理する」ではないでしょうか?しかし、AWSの請求明細は「インスタンス使用料」や「データ転送料」「データベース利用料」など機能カットでの総額となっており、当然のことながらユーザー企業の内部事情を考慮したつくりにはなっていません。従って部署それぞれの利用料を把握するにはもう一歩工夫が必要になります。

そこでシステム運用に慣れた管理者ならば当然に思い浮かべるカード「ログを基にサーバーの利用時間から課金する」、これならどうでしょうか?確かにアマゾン社は詳細なシステム稼働ログを提供しており、日々ブラッシュアップを続ける姿勢も感じ取れるものの、ただ、まだ実運用に乗せるには時期尚早か・・というのが筆者の正直な感覚なのです!

そこで提案したい費用配分方法はふたつ。

  1. 部署ごとにユーザーアカウントを分けて管理する。

  2. 社内向けのプライスリストを制作する。

まずは「1」から。これはAWSを利用するユーザーアカウントを部署単位で分け、ひいては請求書を分けてしまうというもの。AWSの請求書がユーザーと紐づくことを利用したもので、現状最もシンプルで確実な費用配分手段といって良いでしょう。ただし、デメリットもあります。「ユーザーが分かれる=ネットワーク(Amazon VPC)も分かれる」ため、IPアドレスやサブネット、ゲートウェイといったネットワーク構成管理の負担増には目をつぶる必要があります。また従量課金(利用量に応じて金額が変動する)というAWSのサービス特性上、事前の予算化が難しく、ともすれば日本企業に馴染みにくい部分があるかもしれません。

続いて「2」。こちらは、あらかじめ社内提供用のオリジナル価格表をIT部門で定義してしまいます。前述の1にある課題をクリアできるため、ある種理想的な課金の仕組みではあるのですが、いかんせん難易度が高い。システム提供時の平均的なリソース利用量を予測して価格を設定する必要があり、初めてAWSを運用する担当者にとっては雲をつかむような話でしょう。その上見積もりを誤った際にはIT部門が費用を被らなければならない側面も。あと、為替の変動リスクも見逃せません(AWSの請求は「$(米ドル)」です)。

従って落としどころとしては「まずは部署ごとのユーザーアカウント分割。追ってプライスリスト検討」というのが現実路線となり、実際多くのお客様がそうした選択をされています。もちろんAWS運用に慣れたSIerへの相談も併せてご検討くだいませ!

最後に

以上駆け足ではありますが、事業部門が主導するAWS導入の勘所をご紹介させていただきました。「1. 独立したシステムとしての導入」「2. ガイドラインの整備」「3. 体制づくり」「4. 課金管理」と決して平たんな道のりではありませんが、ひとつひとつこなしていけばAWSをいつでも必要なだけ利用できる真の意味でのクラウドサービスとして活用できるでしょう。微力ではありますが、当記事が皆様の日々の業務のお役にたてれば幸いです。

著:江口 智
ITインフラコンサルタント。Amazon Web Servicesの導入コンサルティングや運用支援など、クラウドインフラを軸としたITインフラ支援を得意とする。

Pocket

コメント

「AWS」のイベント・セミナー

開催
AWS Summit Tokyo 2017