情シス記録 クラウドやるときのリソース調達における考え方。
システムリソースを柔軟に欲しい時に調達できる基盤が理想。
現状は過渡期なので、既存の資産／発想とどうおりあいをつけつつ理想に進むか。
◎検討事項。
２．自社ネットワーク経由とするかインターネット経由とするか。（コネクティビティ）
３．リソース占有、共有の影響はもうサービスメニューが多いので１．２．と同列には扱わない。
４．オンプレを選ぶ場合もハード調達とIaas/ベアメタル調達等いろいろ。
◎実際に調達時に契約する内容例。
・ネットワークリソース（FWやL3スイッチとか負荷分散装置とか）
・サーバリソース（いわゆるCPU/Memory/Diskとか）
・ソフトウェアライセンス（持ち込み可能か、月額費用に込みか）
・セキュリティレイヤ（共通化しないと個別最適と青天井）
・サポート体制（問い合わせ、監視等）
◎課金設計は重要。
☆リソースへの課金と運用がマッチするか。例えばサーバ停止するだけで課金が止まるか等。
課金設計においては、無停止運用はデメリット。
夜間バッチの前倒しによる夜間帯のシステム停止とか、いろんな発想が生まれている。
すなわち「時間」リソースの管理を運用設計に持ち込んだ感じか。
◎グローバル連携。
・データセンターのロケーションとデータ配置。
・請求時に使われる為替は何か。適用される法律は。
・仮想データセンター機能によるデータ配置がシンプルかどうか。
◎クラウドの厄介なところ。（解決できるものであり否定ではない）
・カスタマイズと汎用サービスがイマイチ整理されていない。営業も技術者も独自に線を引く。
・ディスクI/Oは厄介。遅い。
・すでに海外技術がベースなので、国内技術者は自信なさげな場合がある。
国内クラウドはネットワークや従量制でない課金等、カスタマイズ相談等、いいところもあるけど。
ただ、Amazonとかのかけている投資額と比較すると、国内勢はつらい。
・クラウドロックはある。
例えば高い課金体系で作ったサーバを、安い課金体系へ移行とかはしにくい。
・占有／共有リソースの違いがパフォーマンス問題につながるとされるけど、明確な数字は出ない。
・クラウド運用スキルがローカルスキル。でもこれを学ばないと運用コストがあがる。
・クラウド標準メニューの精査と検証は、契約前にやっておかないと。
◎今後のロードマップ。
・レイヤーは、データセンター（従来、HWとかファシリティとされていた）とネットワークとサーバ、ミドルウェアの４層で俯瞰。
・ネットワークは帯域保証等、がっちりと作った方がいい。クラウド基盤の前提。
・サーバは、占有、共有等の性能問題をしっかり精査。ディスクは本当に要注意。
・ミドル層は、ライセンスと運用要員のスキルの兼ね合いで、ソフトを選定。
各リソースへのネットワーク経路とデバイス、ID認証を重点運用設計に。
◎クラウド比較のポイント。
・ネットワーク基盤が大前提なので、接続先クラウドとの親和性とクライアントビジネスプロセスとマッチするかどうか。
・データ配置と請求為替、適用法律は契約前に整理。
・バックアップ基盤の考え方をもつ。
・オンプレ連携だけでなく、SaaS連携、インターネット連携と柔軟なネットワーク構成がとれること。
・セキュリティ事故発生に対する説明（調査やログ提出等）がしっかりあること。
・解説書籍が出ているか。（一般化しているか）
・国内企業のサービス撤退リスクはかなり高い。国外はさらに容赦ないかも。
◎クラウド費用例。
・VPN接続料（企業の場合、インターネット直接は少ないかと）
・データ転送料
・リソース使用量
◎まとめ。
・オンプレオンリーのエンジニアは、クラウドの至らぬ点（割り切れる点）を批判しやすい。
・システム設計・構築・運用に、時間短縮の概念が持ち込まれて、クライアントはそれを評価する。
・構築時のエンジニア動員数や検証項目の削減のためにどうするか→当然デフォルトで使うこと。
・クライアント側にも、カスタマイズ独自仕様する点とマニュアル汎用仕様でよしとする点がはっきりさせていく必要がある。概念は２割独自８割汎用。
メール等のグループウェア、誰が使ってもアウトプットは同じになりやすいものは、汎用ラベルをはって、クライアントの要望をシャットアウトする方法も考える。
・目指すべき事は、作った基盤がクライアントの需要を喚起できること。インフラ屋の必至。
