http://www.asyura2.com/14/it12/msg/154.html
| Tweet |
http://itpro.nikkeibp.co.jp/atcl/column/15/081900193/082000002/?ST=cloud
AGC旭硝子（以下、AGC）では、2015年から基幹システムでパブリッククラウド「AWS（アマゾン・ウェブ・サービス）」を使い始めた。現在、物流や販売などを担う国内向け基幹システムを、AWSのIaaS（インフラストラクチャ・アズ・ア・サービス）である「EC2」上に移行している。本格稼働は、2016年春を予定している。2018年までには、基幹システムの7〜8割をクラウドに移行する計画だ。
周囲を見渡すと、このところ同様の検討を進めている企業が急激に増えているように感じる。動機は「今よりコストを下げたい」「経営状況に合わせて柔軟にサーバー数を増減させたい」「そこそこのコストでBCP（事業継続計画）対策をしたい」など、IT部門にとって普遍的なテーマではないだろうか。
「実際に検討を始めたが、なかなか上層部が“クラウドを使っていい”と言ってくれない」という話をよく聞く。また、AWSのIaaSを企業の共通基盤として使うとなると、思いのほか考慮すべき点が多いことに驚かされる。
今回から5回にわたって、実際にAWSを導入したユーザー企業として、AGCの情報システムセンターが経験してきたことをそのままお話したい。我々がAWS導入に当たって、どんなことを“壁”に感じ、それをどう突破してきたのかをお伝えする。
最初の壁はサービス選定
AGCがAWSの導入を検討し始めたのは2014年。あるシステムのハードウエアが保守切れを迎えることがきっかけだった。従来はメインフレーム上で動作していた専用システムだったが、保守切れを機に欧州SAPのERP（統合基幹業務システム）を採用して一から作り直すことになった。その動作環境として、オンプレミスかクラウドかを検討した。
クラウドを選択した主な理由は、「システム開発/運用のコストや作業負荷を下げたい」「現実的な金額でBCP対策を実施したい」の2点。いずれもクラウド活用の利点として代表的なものだ。長期にわたって保守/運用し、万全なBCP対策が求められる基幹系システムこそ、クラウドのこうしたメリットが生かせると考えた。そこで、本腰を入れて検討を進めた。
その際に直面した最初の壁は、「どのクラウドサービスを選べばいいの？」ということだった。昨今のクラウドブームのおかげで、一般のユーザー企業では把握しきれないほどクラウドサービスの選択肢は多くなってきている。
まずは手軽に使い始められることを重視してサービスを選び、システムの規模が大きくなるにつれて使うサービスを増やしたり、切り替えたりするという方法もある。だが「その考え方は危険だ」と我々は直感的に感じていた。基幹システムのプラットフォームとしてIaaS環境を用意するというのは、オンプレミス環境のデータセンター設計に近い検討が求められる。短期間でサービスを切り替えることになれば一から検討し直すことになるため、無駄が大きい。
page: 2
つまりクラウドサービスの選択は、失敗できない重大な作業だ。AGCでは慎重に検討を行い、最終的にAWSを選択した。とはいえ、選定に多大なコストと時間を掛けたかというと、実はそうでもない。意外にもあっさりと、やるならAWSということに落ち着いた。
なぜ、あっさりと決めることができたのか。今になって振り返ると、検討の前段階で、「基幹システムのプラットフォームとして、IaaSに何を期待するか」という“軸”のようなものが、我々の中である程度明確だったからではないかと思う。
我々が重視していたのは「標準サービスがとにかく充実していること。標準外の個別リクエストには応えてくれなくてよい（むしろ応えようとしない方が良い）」であった。ユーザーからの個別の要求に応えようとしてくれるクラウドサービスは一見ありがたいが、その分料金は高くなるだろうし、新サービスの開発スピードも遅くなるはずだ。我々は初めから、移行するシステムのインフラはクラウド側の標準に作り替えるつもりでいたし、どうしても標準外のサービスが必要なら「オンプレミス環境に残せばよい」という考えでいた。
このほかにも、譲れないポイントが三つあった。まず「日本にデータセンターがあること」。詳しくは後述するが、法律面を考えればこれは重要な点だった。次に「オンプレミス環境と専用線で接続できること」。ネットワークの安全性を確保するために、この要件は譲れなかった。最後は「セキュリティに関する監査証跡が、標準サービスとして提供されること」。内部統制に関する既存の運用方法は極力変更したくないという事情があったため、これも必須事項だった。
我々がクラウドサービスを選定していた2014年春時点では、これらを全て満していたのはAWSだけであった。このため、あまり混乱することなく「やるならAWSで、無理なら当面先送り」という結論を得ることができた。
「クラウドなんて使って大丈夫なの？」にどう答えるか
このように徹底的な調査を実施したのち、我々担当者は「クラウドを導入しても大丈夫。いや導入すべきだ」という思いを新たにした。だが、これを組織全体の思いにするのは、容易なことではない。これが、我々にとっての次の壁だった。
page: 3
上層部などには「基幹システムにクラウドを使って本当に大丈夫なのか？ 安定するのか？」という不安が少なからずあった。誰にどのように話を持っていくか、メリットとデメリット（リスク）をどう説明するかは、会社の規模や業界、IT部門の役割や立ち位置などによって異なる。どこでも通じる“銀の矢”的な解決策はないように思う。
AGCの場合、時間と根気が必要だったのはリスクをいかに回避するかという点の説明だった。「なぜ危険か」を説明するのは容易だが、「なぜ大丈夫なのか」を心から納得してもらうことは難しい。
そこで我々は、（1）法律面の確認、（2）内部統制との整合性、（3）セキュリティリスク、（4）その他社内規定との整合性という四つの側面で評価を行い、その結果を説明するというアプローチを取った（図）。リスク評価の結果に100％の保証はないが、多方面から検討することで結果に厚みと納得感を与えたかったのである。それぞれについてどのように検討したのか、一つずつ解説しよう。
図●四つの側面からAWSの利用可否を検討
[画像のクリックで拡大表示]
（1）法律面の確認
クラウドにデータを置いて法律的に問題はないのか。これが、我々が最初に検証しなければならないと考えた問題であった。既に取り組んでいる企業も多いことから、何となく大丈夫な気はする。だが、明確な情報はほとんど手に入らなかった。どのように調べたらよいのか。その方法からして初めは混乱した。
我々はまず、「日本のデータセンターからはデータを出さない」ということを前提に置いた。これによって、検討範囲を国内法に限定した。その上で、取り扱うデータの種別ごとに、関連する法令を洗い出した。そしてその法令に、データの置き場所を限定するような記載や考え方があるか、という観点で確認していった。
page: 4
その結果、我々は「基本的にデータに関してはどのような管理がされているかが重要であり、管理されていることが説明できれば、置き場所がオンプレミス環境であってもクラウドであっても問題にならない」という結論を出した。なお、これはあくまでも国内法に限っての結論である。欧州のデータ保護指令など、データの置き場所自体に規定があるケースもあるので注意が必要だ。
（2）内部統制との整合性
AWSを使った場合、内部統制の規定に違反しないかという点も調査した。システム関連の統制項目を、（A）自社で従来と同じコントロールができる、（B）従来と同じコントロールが可能だが実施者が自社でなくAWSになる、（C）従来と同じコントロールができなくなる、の3つに仕分けた。
その際に参考にしたのは、第三者によるAWSの監査レポートである。結果としては、ほとんどの項目が（A）で、一部（B）に該当するものがあった。例えば「データセンターの入退室管理」などは、実施者がAGCからAWSに変わるので（B）となる。問題となるのは（C）だが、これは1項目もなかった。
（3）セキュリティリスク
セキュリティに関するリスクは、クラウド利用の際に多くのユーザーが気にする点だろう。実は、前出の2項目に比べると、そこまで力を入れて調査しなかった。というのも、この手の情報は比較的容易に入手できる状態になりつつあるからだ。
特にAWSは、セキュリティ関連の情報が幅広く公開されている。また、自社でのAWS活用ノウハウをパッケージ化したNTTドコモのサービス「ドコモ・クラウドパッケージ」のようなサービスを利用するのも、一つの手ではないかと思う（関連記事：なぜドコモがAWSを“担ぐ”のか？ 「ドコモ・クラウドパッケージ」の真の狙い）。
page: 5
（4）その他社内規定との整合性
これ以外にも、社内独自の規定について準拠状況を確認した。情報セキュリティポリシーや、重要文書のバックアップ方針などが一例だ。いずれも、問題がないことが分かった。
このように、四つの側面について入念に調査を実施し、その全てについて大きな問題がないことを確認した。これを基に、上層部への説明を実施した。当然ながら、1回で社内の合意を形成できるわけではない。様々な立場・部署の担当者に向けて、3回、4回と説明会を重ねた。こうしてじわじわと「クラウドを導入しても大丈夫」という認識を広げ、最終的にクラウド採用の決定にこぎ着けた。
コスト削減効果が見えていたから、検討に労力を割けた
AGCの場合、クラウド導入の検討開始から決定までには3カ月ほどの時間をかけた。検討範囲は多岐にわたったため、それなりに人と時間を割く必要があった。ここまで検討にリソースを費やせたのは、初期段階でAWSでかかるコストをシミュレーションした結果、メリットが明らかになったからにほかならない。
もともと、開発環境であれば、使わないときに停止するなどの工夫によってコスト削減効果がありそうなことは分かっていた。その後詳細にシミュレーションしたところ、本番環境であっても、上手にAWSを使えばインフラの運用/保守の部分だけで見ても利がありそうだという結果が出た。この結果があったからこそ、AWS利用の可否を検討する作業にここまで時間と人を割くことができたわけだ。改めていうまでもないが、コスト面の評価は非常に重要である。
次回は、導入の意思決定後に話を進める。「どのような考え方でクラウドの基盤設計を行うべきか」について、掘り下げて解説する。
浅沼 勉
［2］便利な新機能が続々、うれしい半面苦労も絶えず
http://itpro.nikkeibp.co.jp/atcl/column/15/081900193/082000003/index.html?ST=cloud
AGC旭硝子（以下、AGC）がAWS（アマゾン・ウェブ・サービス）の採用を決定したのは2014年8月。物流や販売などを担う、国内向け基幹システムへの導入が決まった。
そのころには既に、AWSが社内外で広く使われるようになるのではないかという手応えがあった。そのため早々にAGCグループ全体でAWSを利用することを意識し、そのための基礎作りを行った。その過程で、複数の壁に遭遇した。
技術標準を定めて統制を強化
AGCが行った基礎作りは、大きく二つある。AWSの技術標準を定めることと、各機能をサービスとして使える共通基盤を作成することだ。まず、技術標準について説明する。
AWSが持つ豊富な機能群を活用するには、入念な調査をして利用する機能を選択し、どんな使い方をするかを決める必要がある。新たにAWSを利用するシステムごとに、それぞれの担当者が調査/決定をするのは非効率で、統制も効かなくなる。
そこで我々は、AGCにおけるAWSの技術標準を定めた。具体的には、ネットワーク、セキュリティ、アクセス管理、バックアップなどに関して、AWSのどのサービスや機能をどういう構成・設定で使うかについて定めた。
中でも慎重に考慮すべきポイントがネットワークである。パブリッククラウドを企業が利用する上で、間違っても他社と不正に接続できてはならない。そこでAGCは、仮想プライベート空間を作れる「Amazon VPC（Virtual Private Cloud）」と、オンプレミス環境とAWSを専用線で結ぶ「AWS Direct Connect」を利用した。Amazon VPCでAWS上にAGC専用の論理区画を作り、そこにAWS Direct Connectで専用線接続することで、AWSを社内LANの延長にあるデータセンター群のように扱えるようにした。
page: 2
これら二つの機能を使ってAWS上に企業システムを構築する方式は、今やデファクトスタンダードともいえるほど一般的になっている。二つの機能があるからこそ、AWSの企業利用が大きく伸びたのではないだろうか。AGCはこれに加えて、ネットワークアクセスを制限できる「Network ACL」や「Security Group」も活用している。これによって、VPC内でも細かくネットワークの制御ができている。
セキュリティの技術標準は3点で検討
セキュリティに関する技術標準は、OSより上位の層、OSより下の層（ハイパーバイザー部分）、物理機器の3点で検討した。
OSより上は、ウイルス対策ソフトやセキュリティ修正プログラム、OS/パッケージソフトが持つ個人認証機能を使えば、オンプレミス環境と同様にセキュリティを確保できる。
OSより下は、従来でいえばデータセンターのセキュリティに当たる。これを、AWSの独自機能で行うことになるので、綿密に技術標準を定めた。仮想マシンの作成（従来ならサーバーの設置）と削除（従来ならサーバーの撤去）をするための権限は、「AWS Identity and Access Management（IAM）」とIAMの「ロール」と呼ばれる機能で制御している。作成や削除の作業履歴は、ログを記録できる「AWS Cloud Trail」で保持している。これは、従来ならデータセンターでの作業記録に相当する。
物理機器については、AWS側のハードディスク上のデータを、AGCが希望したからといって物理的に消去してもらうことはできない。そこで、データは暗号化し、AWSの第三者機関の厳しい監査に従った運用を行うことでカバーしている。
どんなシステムでも使う機能を共通基盤として整備
こうした技術標準に基づいたシステムを手軽に構築できるように、共通基盤も用意した。どんなシステムでも必ず使う、コマンドやバックアップ、監視の機能をサービスとして設けた。
page: 3
特に手間を掛けて作り込んだのが、コマンドである。AWSの標準サービス・機能を組み合わせ、AGC独自のコマンドで呼び出せるようにした。AWSでは標準のコマンドで、仮想マシンの停止/起動やバックアップができる。多数の仮想マシンを管理するのに便利な半面、他のシステムを誤って止めてしまうリスクもある。このリスク回避のために、コマンドを実行する人のアクセス権と、個々の仮想マシンに付与した「タグ」と呼ばれる属性データを照合する仕組みを設けた。アクセス権がない仮想マシンへのコマンド誤発行を防止し、安全性を高めている。
バックアップについては、AWSが標準機能として用意する数種類のバックアップ用コマンドを使うだけでなく、ストレージサービス「Amazon S3」に専用の仮想マシン経由でファイルをバックアップできるようにした。バックアップしたファイルにはタグを付けて所有者を把握し、その部門に課金できるようにした。
システム運用に不可欠な監視機能も、共通基盤に用意した。CPUやメモリーなどの性能監視には、AWS標準の監視機能「CloudWatch」を活用。CloudWatchで自動的に保管される2週間分のデータの保持方法を、独自に設計した。OS上のプロセス監視はAWSではできないので、オープンソースのソフトウエアを用いて実装し、幅広いシステムに展開しやすくした。
ぶつかった二つの壁
技術標準や共通基盤の作成には、様々な苦労があった。パブリッククラウドであるAWSでは、オンプレミス環境での作り方が通用しないからだ。特に大きかった壁は二つある。
一つは、AWSが続々とリリースする新機能だ。便利な機能が使えるようになるのは本来うれしいことだが、苦労もある。
page: 4
例えば、共通基盤に用意した監視機能。当初は仮想サーバー「EC2」の死活監視機能として、ダウンしたものを見つけて再起動させる独自機能を作り込もうとした。ところが、EC2の自動リカバリー機能が前触れなくリリースされ、独自機能は不要になった。
せっかく作った機能がお蔵入りになることもある。データを仮想ストレージのS3にバックアップするための通信経路を確保するために独自のプロキシー機能を開発したが、2015年5月にVPC用「S3 Endpoint」という同様の標準機能が登場した。高速で安全性が高いため、今後こちらに変更する。
二つ目の壁は、ユーザー企業にとって制御不能なことへの対応である。クラウドといってもAWSのデータセンターでは物理機器を使っており、メンテナンスが必ずある。事実、この10カ月間に仮想サーバーが停止する可能性が2回あった。
そのうちの1回は、2015年3月の通信系のメンテナンスである。これは、通信経路を多重化しておいたため全く問題なかった。もう1回は、2014年9月。二晩にわたって大規模なセキュリティホール対策が行われた。事前通知の上で、仮想サーバーが多数再起動される可能性があった。当時、AWS上で動かしていたのは開発環境だけだったので影響はなかったが、「パブリッククラウドを利用する上では、自社では制御できない状況がある」ということを目の当たりにした。この経験を基に、本番環境の一部は、東京リージョン内の複数のデータセンター（アベイラビリティゾーン）をまたぐ構成にした。
運用コストを戦略的に削減
こうした壁の一方で、コスト節約を意識した運用が可能になるというクラウドならではのメリットが生まれた。オンプレミスの機器は、一度リースやレンタル契約をしたら、使うか使わないかに関わらず、毎月一定の料金が掛かる。電気でいえばつけっぱなしも同然だ。
これに対してAWSの仮想サーバーEC2は、使った分だけ1時間単位で課金される。1週間のうち日曜日に停止すれば14％（7分の1)、加えて月曜日から土曜日についてもそれぞれ半日停止すれば合計で57％のコスト削減になる。電気なら「使わない時は消す」のは当たり前だが、これと同じことがシステム運用でも可能になるのである。
page: 5
さらに戦略的にコスト削減を進めることもできる。開発/検証環境なら、「負荷の低い時期は低性能なEC2インスタンスに切り替える」「通常は停止しておき、トラブル発生時や追加開発時だけ動かす」といった運用を行っている。本番環境でも、本稼働前はインスタンス数を最低限に抑えたり、低性能のEC2に変更したりできる。こうした稼働計画を上手に立て、積極的にコストダウンする運用を実施した（図）。その結果、社内でAWSを採用する案件が急増した。
図●AWS利用料は当初の予測を大幅に下回っている
[画像のクリックで拡大表示]
現在、AGCでは複数のシステムでAWSを活用している。いずれも技術標準に準拠し、共通基盤を活用したものだ。AWSの豊富な機能を、有効に、統制が取れた形で使うには、技術標準と、サービスとしての共通基盤が必要だということを実感している。システム部門にとっては、AWSの標準機能の進化を積極的に取り入れる精神も必要になる。
［3］社内でAWSファンが急増、一方で情シスはピンチに
http://itpro.nikkeibp.co.jp/atcl/column/15/081900193/082000004/
前回、AWS（アマゾン・ウェブ・サービス）を基幹システムに使うに当たって準備した、共通基盤について説明した。今回は次なる壁として、この基盤にいかに社内ユーザーを呼び込んでいくかについてお伝えする。
次期の主要インフラにAWSを採用するという方針が決まってから、我々情報システムセンターは、製造部門や研究開発部門などいくつかの部署を対象に、AWSに関する説明会を実施した。そこでは、「AWSの超入門」「代表的なAWSのサービス」「AGC旭硝子におけるAWSの使い方（指針）」といった項目について説明した。
反応は実に様々だった。「ぜひ、次期システムにAWSを使いたい」と言ってくれるユーザーもいれば、「コストが見合うのなら検討する」という慎重派のユーザーもいた。もちろん、「自分が担当しているシステムは、AWSでは実現できない」という人もいた。
社内からの相談が急増し「これはヤバい」
いずれにせよ、説明会を通じて感じたのはクラウド技術に対するユーザーの熱意である。この新しい技術を使うことで、今までできなかったことができるのではないか。今困っていることが解決されるのではないか。そういう期待感を抱かせるのに十分な魅力が、AWSには確かにあるのだと思う。
説明会の甲斐あってか、その後AWS利用の相談が社内から頻繁に舞い込むようになった。問い合わせは、「本当にシステム運用の負荷から解放されるのか」とか、「コストはどれくらい削減できるのか」といった一般的なものがほとんどだった。
ただ新鮮だったのは、顔見知りのユーザーだけでなく、今まで全く連携していなかったような部署の社員が人づてにAWSのことを聞きつけて、我々情報システムセンターに連絡してくるケースが少なくなかったことだ。AWSの魅力が、部署の垣根を越えて伝わったようだった。
それ自体は望ましいことだ。ただ、相談が増えるにつれ我々には「これはヤバい」という危機感が高まっていった。
page: 2
社内AWSコンサルが足りない！
AGC旭硝子（以下、AGC）でAWSを利用する上では、インフラの統制を最大限に効かせるために「ユーザーに開放するAWSの操作を極小化する」ことを基本方針とした。このため、最も基本的な作業である仮想マシン（サーバー）の作成ですら、ユーザーの申請を受けて情報システムセンターが実施することにしている。
またAWSを使いたいと思っても、ユーザーには分からないことが多い。「そもそもAWSで実現できるのか」「AWSを使った場合にどのようなシステム構成になるのか」「費用はどの程度か」といった基本的な疑問でも、自己解決できるユーザーはまれである。その都度、我々情報システムセンターが相談に乗らなくてはならない。
こうした経験を通じて、社内でAWSの利用を定着させるには、3つの役割が必要になると気付いた。AWS利用の枠組みやルールを検討/説明するマネージャー、ユーザーの要求をヒアリングしてAWSでどう実現するかを考えるアーキテクト、ユーザーに代わってAWSの操作をするオペレーターである。
案件が増えるにつれ、かなり早い段階で、情報システムセンターの担当者だけではこの三つをこなしきれなくなることが想定できた。このままでは、情報システムセンターがAWS活用のボトルネックになりかねない。問題を放置してAWSの魅力ばかりを伝えていたら、「スピード感が魅力のサービスなのに、情報システムセンターの対応が遅くて進まない」ということになり、せっかく集めたファンが離れてしまう恐れがある。
「AWSカタログ」でボトルネックを取り除く
我々情報システムセンターは、このボトルネックを「AWSカタログの作成」というアプローチで解消しようと考えている。これは2015年8月現在、進行中のプロジェクトである。このプロジェクトでは、4種類のコンテンツを用意し、AWSを知らないユーザーが実際に利用できるようになるまでを段階を追ってサポートする計画だ（図）。4種類のコンテンツとは次のようなものである。
図●「AWSカタログ」の4種類のコンテンツ
[画像のクリックで拡大表示]
page: 3
1. パンフレット
AWSの基本知識を、数ページにまとめたもの。「これさえ読めば最低限のことは分かる」という資料である。さらに詳細な資料（2. の「AWS活用コンセプト」）もあるが、あえて簡易版を用意した。AWSに対する敷居を下げるとともに、まずはユーザーに自習してもらうのが狙いである。
2. AWS活用コンセプト
AGCにおける、基本的なAWSの利用ルールや利用方法を説明する資料。利用ルールとは、「AGCにおいて標準で使えるサービス」「許可されるネットワーク経路」「権限管理の考え方」などである。このほか、ユーザーとAWSとの役割分担、社内の共通基盤チームが提供する標準サービスの機能説明、部門ごとの課金/請求の枠組みなども盛り込む。これを要約したのが、1. の「パンフレット」である。
3. 標準アーキテクチャーカタログ
基幹システムにAWSを採用した場合に考えられる構成を図示したもの。代表的なシステムの規模や、要求される可用性のレベルなどを数パターン用意する。ユーザー側で、自分のシステムにAWSを導入した場合にどのような構成になるか、どの程度の費用が掛かるのか、といった見当が付けられるようになる。
4. 利用申請ポータル
仮想マシンの作成をはじめとする各種の作業を定型化し、「利用申請ポータル」というWebサイトから一元的に情報システムセンターに依頼できるようにする。定型化することでユーザーの作業を単純化。作業負荷をその都度見積もる必要もなくす。
page: 4
情シスが、本来担うべき役割に注力
これらのコンテンツを用意することで、大きく二つの効果を創り出せると考えている。
一つは、AWSについて「説明できる人」が増えること。基本事項がまとまった定型資料を使えるようになるためだ。
もう一つは、AWSの操作などの作業を外部の協力会社に委託できるようになること。作業が定型化されるので、外部に依頼しやすい。その結果、情報システムセンターのメンバーは、AWS活用のルール作りやシステム設計などの本来担うべき役割に注力できるようになる。
以上、今回はクラウド活用を広めるための手順やドキュメント整備の考え方について、我々情報システムセンターの取り組みを紹介した。AWSを社内で広く活用する際に、中途半端な利用ルールで展開を始めてしまうと収拾がつかなくなる。
特にAGCでは、AWSの環境を情報システムセンターで一括管理するという統制方針を取っている。このため、AWSを社内で横展開するための準備には、共通基盤の構築と同じレベルで注力すべきと我々は考えている。
浅沼 勉
AGC旭硝子 情報システムセンター グローバルIT企画グループ 主席
アクセンチュアにてITコンサルティング業務に7年間従事後、2011年にAGC旭硝子に中途入社。事務処理系システムの企画/構築、全社のインフラ基盤の戦略企画に携わる。CISA（公認情報システム監査人）、AWS認定ソリューションアーキテクト-プロフェッショナル
- アマゾンのドル箱となったAWSがこれほど破壊的である理由 AmazonをEコマースの会社だと思っているなら、認識を改めよ てんさい（い） 2015/11/02 11:08:19
(1)
- クラウドが提供すべき7つの自由を実現するAWSの新製品 パブリッククラウド市場のAmazon Web Services てんさい（い） 2015/11/02 11:22:21
(0)
- クラウドが提供すべき7つの自由を実現するAWSの新製品 パブリッククラウド市場のAmazon Web Services てんさい（い） 2015/11/02 11:22:21
(0)
投稿コメント全ログ コメント即時配信 スレ建て依頼 削除コメント確認方法
スパムメールの中から見つけ出すためにメールのタイトルには必ず「阿修羅さんへ」と記述してください。すべてのページの引用、転載、リンクを許可します。確認メールは不要です。引用元リンクを表示してください。
