Amazon Web Services ブログ

グローバルマルチメディア通信社であるロイターがアマゾン ウェブ サービスをどのように利用しているかをご覧ください

私は Thomson Reuters でソリューションアーキテクトを担当している、Romeo Radanyi です。チームがクラウドテクノロジーを理解したり、導入できるようサポートしています。企業レベルの標準規格の設定、人工知能や機械学習の計画の推進、そして数多くのロイターシステムの構築にも携わっています。また、データサイエンスとJupyterノートブックの初心者向けのコースを A Cloud Guru で開発して提供しました。 ロイターは、世界最大のマルチメディアニュース源で、みなさんが目にしたり、読んだり、聞いたりするニュースネットワークへのニュースソースを提供しています。弊社は、いわば卸売業者の一種です。つまり、BBC、CNN、ニューヨークタイムズ、ワシントンポスト、そして他の世界中のお客様向けに、さまざまな形式で生のニュースを販売しています。 このブログ投稿では、ロイターがコンテンツの大部分を AWS に移行した方法を取り上げます。AWS のターンキーオブジェクトストレージソリューションである Amazon Simple Storage Service (Amazon S3) とそのコンテンツ配信ネットワーク (CDN) である Amazon CloudFront を使用して、どのように世界中の何十億もの人々に日々コンタクトするのかを説明します。 レガシーシステムが直面した課題 弊社は 5年前に、新しく開発したすべてのロイターシステムの戦略的プラットフォームとして AWS を選択しました。あなたは、「なぜ?」と質問するかもしれません。 ロイターは、さまざまなフォーマットでコンテンツを作成して配信しています。フォーマットには、動画、画像、テキスト、さらにはニュース速報でのライブストリームなどがあります。さらに、記録保管として1896年当時の物理テープもありました。最後に重要なことですが、弊社は実質的にミニデータセンターである 200 を超えるニュース局から成るグローバルな規模を持っています。これらの局では、現場で生のコンテンツを撮影し、編集した主な情報源を扱っています。世界中のこのようなコンテンツすべてをさまざまなフォーマットやフレームレートで、瞬時に保存、変換、提供することは簡単な作業ではありません。 最初は、コンテンツの保存、変換、提供、チームが学習してプロセスに統合するために必要な工数などの一部の作業をサードパーティに頼ってました。サードパーティと協業した際、サービス停止やサービス関連の問題を解決するのに課題が発生し、それらを改善するためのプロセスを実行するまで時間がかかりました。ロイターチームからの広範なサポートがあっても、コストは増加していました。様々な記録媒体において、テープは安価で使いやすいですが、取り出しに時間がかかるため、コンテンツを世界中のニュースアウトレットに配信して販売するのはほぼ不可能です。弊社の実際の局において、それらのすべてのミニデータセンターをそれぞれが島であると想像してください。コンテンツを編集用に暫定的に保管するための拡張可能な空間がない限り、共同作業するのは難しいです。 結果として、ロイターは 3 つの主な課題に直面していました。一つ目は、第三者にすべてのメディア資産の保管を委託するとか、高価な CDN を使用することが、将来的な選択肢でなくなりました。二つ目は、記録保管されているテープが広範囲なコレクションのため、情報を迅速に配布することが困難でした。三つ目は、弊社の実際の局では、島のようなデータセンターすべての間で結びつきが不十分なため、チーム間で協力し合うことがうまくいきませんでした。 AWS Glue の選択 AWS と Amazon S3 に慣れるにつれ、API と HTTPS 呼び出しによる幅広い機能と使いやすく、組織全体の課題に対する完璧なソリューションであることがわかりました。さらに、AWS と Amazon S3 […]

Read More

Amazon EFS を Amazon ECS と AWS Fargate で使用するための開発者ガイド – パート 1

 Amazon Elastic Container Service (ECS) と Amazon Elastic File System (EFS) のネイティブ統合が最近導入されました。Amazon ECS は、クラウド専用に構築され、他の AWS のサービスと統合されたフルマネージド型のコンテナオーケストレーターサービスです。ECS は、Amazon EC2 と AWS Fargate の両方で、(いわゆるタスクにラップされる) コンテナのデプロイをサポートしています。Amazon EFS は、ECS や EC2 インスタンスなどの他の AWS のサービスで使用するように設計された、フルマネージド型の柔軟な共有ファイルシステムです。Amazon EFS は透過的にスケーリングし、データをレプリケートし、アベイラビリティーゾーン全体で利用できるようにし、複数のストレージ階層をサポートしています。これにより、大部分のワークロードの要求に対応しています。 この統合は、EC2 インスタンスまたは Fargate を使用するすべての ECS のお客様がご活用いただけます。この統合は、Fargate の、AWS が最近リリースしたプラットフォームバージョン 1.4 で有効になりました。 開始する前に、この統合はオーケストレーター固有であることをはっきりさせておくことが重要です。これは、ECS on EC2 と ECS on Fargate の両方に適用される Amazon ECS タスクレベルの設定だからです。Amazon EKS […]

Read More

Amazon EFS を Amazon ECS と AWS Fargate で使用するための開発者ガイド – パート 3

 Amazon EFS を Amazon ECS と AWS Fargate で使用する方法に関するこのブログ記事シリーズのパート 3 へようこそ。参考までに、このブログ記事シリーズは次のように構成されています。 パート 1: このブログ記事は、この統合の必要性とその範囲に関する背景情報を提供し、この機能により道が開かれ、お客様に役立つユースケースとシナリオの概要を示します パート 2: ECS と Fargate に基づきコンテナをデプロイする際の EFS のセキュリティの仕組みの詳細と、リージョンごとの ECS と EFS のデプロイのベストプラクティスに関する高レベルの考慮事項を扱います パート 3: [このブログ記事] コンテナ化されたアプリケーションの再利用可能なコードとコマンドを含む実用的な例を紹介します。アプリケーションは EFS を使用した ECS タスクにデプロイされたものです この記事では、パート 1 とパート 2 で学んだことを試すためのサンプルコードを作成します。このブログを 2 つのメインブロックに分割します (2 つの個別の例を使用して)。その 2 つは以下のとおりです。 ファイルシステムの永続性を必要とするアプリケーションを実行するためのスタンドアロンのステートフルタスク 共有ファイルシステムに並行して複数のタスクにアクセスする これらの背後にある理論について詳しく知りたい場合は、パート 1 をご覧ください。次に、サンプルコードについて詳しく説明します。 これらの例では、ECS タスクは Fargate で実行されますが、EC2 […]

Read More

Amazon EFS を Amazon ECS と AWS Fargate で使用するための開発者ガイド – パート 2

Amazon EFS を Amazon ECS と AWS Fargate で使用する方法に関するこのブログ記事シリーズのパート 2 へようこそ。参考までに、このブログ記事シリーズは次のように構成されています。 パート 1: このブログ記事は、この統合の必要性とその範囲に関する背景情報を提供し、この機能により道が開かれ、お客様に役立つユースケースとシナリオの概要を示します パート 2: [このブログ記事] ECS と Fargate に基づきコンテナをデプロイする際の EFS のセキュリティの仕組みの詳細と、リージョンごとの ECS と EFS のデプロイのベストプラクティスに関する高レベルの考慮事項を扱います パート 3: コンテナ化されたアプリケーションの再利用可能なコードとコマンドを含む実用的な例を紹介します。アプリケーションは EFS を使用した ECS タスクにデプロイされたものです このブログ記事は、Amazon ECS と AWS Fargate を使用している開発者で、Amazon EFS との統合を使用して、各リージョンで弾力性があり、スケーラブルなステートフルサービスをデプロイする方法を学びたい方を対象としています。 パート 3 は、このすべての理論を実践するパートです! 可用性、コスト、拡張性のための Amazon ECS と AWS Fargate アーキテクチャ Amazon ECS は、リージョン別に分散されたコンテナオーケストレーターで、AWS […]

Read More

AWS DMS を使用して Amazon Aurora for PostgreSQL のメジャーバージョンへのアップグレードを最小ダウンタイムで実現する

AWS は 2 つのマネージド型 PostgreSQL オプションを提供しています。Amazon RDS for PostgreSQL と Amazon Aurora PostgreSQL です。Amazon RDS または Aurora がデータベースエンジンの新しいメジャーバージョン (PostgreSQL 10 から 11 など) をサポートしている場合、DB インスタンスを新しいバージョンにアップグレードできます。メジャーバージョンのアップグレードには、既存のアプリケーションとの下位互換性がない可能性があるデータベースの変更が含まれる可能性があります。詳細については、「Aurora PostgreSQL 向けの PostgreSQL DB エンジンをアップグレードする」と「Amazon RDS を PostgreSQLのメジャーバージョンとマイナーバージョンにアップグレードするためのベストプラクティス」を参照してください。 Amazon RDS と Aurora のどちらにも、DB インスタンスを変更することにより、メジャーバージョンのアップグレードを手動で開始するオプションがあります。これは、インプレースアップグレードとも呼ばれ、アップグレードプロセス中にアプリケーションのダウンタイムを必要とします。また、アップグレードで問題が発生した場合は、最新のバックアップを復元する必要があります。したがって、このオプションはすべてのワークロードタイプに望ましいとは限りません。別のアプローチは、メジャーバージョンのアップグレードに AWS Database Migration Service (DMS) を使用することです。AWS DMS は、PostgreSQL 論理レプリケーションを使用して、2 つのメジャーバージョン間のデータをほぼリアルタイムで同期します。AWS DMS は、次の要件を満たしている場合にのみ使用してください。 特定のメジャーバージョンで利用できるインプレースアップグレードオプションがない Aurora クラスター内の少数または一部のデータベースをアップグレードする必要がある アップグレードプロセスに必要なダウンタイムを最小限に抑え、カットオーバーで問題が発生した場合に古いインスタンスへ素早くロールバックできるオプションを確保したい […]

Read More

Amazon Neptune を使用して顧客識別グラフを作成する

顧客識別グラフは、プライバシー保護に準拠した方法を用いて、クッキー、デバイス識別子、IP アドレス、E メール ID、および内部エンタープライズ ID などの複数の識別子を既知の個人または匿名プロファイルにリンクすることにより、顧客と見込み顧客の単一の統合ビューを提供します。また、デバイスやマーケティングチャネル全体での顧客の行動や好みをキャプチャします。これは中央ハブとして機能し、ターゲットを絞った広告、顧客体験のパーソナライズ、およびマーケティング効果の測定を可能にします。 この記事では、AWS で顧客識別グラフを作成する方法の概要を説明し、主要なビジネスドライバー、課題、ユースケース、顧客の成功事例、およびソリューションの利点を確認します。また、ソリューション、サンプルデータモデル、AWS CloudFormation テンプレート、および開発を開始するために使用できるその他の技術コンポーネントについても説明します。 次の図は、デバイス識別子、クッキー、ブラウザ、動作など、特定のユーザーに関するデータのコレクションを顧客識別グラフプラットフォームで示しています。これにより、ID 解決、スコアリング、パーソナライズ用のオーディエンスセグメントの作成が行えるようになります。 ソリューションは、クラウドの専用グラフデータベースである Amazon Neptune で構築します。Amazon Neptune は何十億もの相互接続された関係を保存およびナビゲートするのに理想的で、リアルタイムの広告およびマーケティングアプリケーション向けにミリ秒のレイテンシーをサポートします。このソリューションは、機械学習モデルの構築、トレーニング、開発のためのフルマネージドプラットフォームである Amazon SageMaker も使用しています。このソリューションでは、ホストされた Jupyter ノートブックを提供できる Amazon SageMaker を使用して、顧客識別グラフデータをロードし、一般的なユースケースに対してクエリします。 プライバシー保護に準拠したカスタマーエクスペリエンス マーケティング担当者、広告主、デジタルプラットフォームは、顧客のニーズを特定、理解、予測し、さらにプライバシー保護に準拠した方法を使用してエクスペリエンスのパーソナライズを大規模に行う必要があります。 このような期待に応えることは、多くの面で困難に直面します。ビジネスの観点からは、マーケティング、販売、ロイヤルティなどの企業サイロからデータを集約する必要があります。テクノロジーの観点から見ると、グローバルに拡張できる安全で柔軟なデータベースプラットフォームが必要です。これにより、デバイス、顧客 ID、チャネル、および設定間の相互に関連する何十億もの関係について、リアルタイムの顧客識別および行動グラフを継続的に維持できます。 AWS で顧客識別グラフソリューションを構築する 顧客識別グラフソリューションにより、参照アプリケーションがもたらされます。そのため、独自のビジネスルールを使って、コスト効率が高く、スケーラブルで、安全で、可用性の高い顧客データプラットフォームを構築できます。顧客シグナルにリアルタイムで応答して、広告およびマーケティングアプリケーションとカスタマージャーニーオーケストレーションを自動化できます。 このソリューションにより、マーケッター、アドテック、マーテック、ゲーム、メディア、およびエンターテインメント企業は、何百万もの顧客プロファイルの何十億もの関係から洞察をリアルタイムでキャプチャしてアクティブ化できます。Zeta Global、NBCUniversal、Activision Blizzard などのお客様は、Amazon Neptune を使用して識別グラフを作成し、消費者のジャーニーをキャプチャして、何百万ものユーザーのために広告、コンテンツ、ゲーム内体験をパーソナライズしています。 このソリューションには、サンプルデータモデル、CloudFormation テンプレート、Amazon SageMaker ノートブックが含まれており、データベースで一般的なユースケースをクエリすることができます。完全な顧客識別グラフソリューションは、通常、取り込みパイプライン、データ検証、クレンジング、ID 解決アルゴリズム、ID グラフデータベース、およびオーディエンスセグメンテーションで構成されています。この記事では、Neptune データベースへのデータの取り込み、相互に関連するプロファイルをキャプチャするためのデータモデリング、およびクエリメカニズムに焦点を当てます。これにより、クロスデバイスグラフ、オーディエンスセグメンテーションなどのユースケースをサポートます。 ユースケース このソリューションの一般的なユースケースを次に示します。 クロスデバイスと関心グラフ – カスタマージャーニーとデバイス全体で費やした時間を分析して、特定のユーザーの関心を見つます。これにより、広告をパーソナライズします 決めかねている消費者を納得させる – 以前訪問したウェブサイトに基づいて e […]

Read More

AWS Snowball Edge での AWS Identity and Access Management

お客様の多くは、安全なデータ転送とエッジコンピューティングアプリケーションのために AWS Snowball Edge デバイスを使用しています。最近、AWS は Snowball Edge での AWS Identity and Access Management (IAM) のサポートを発表しました。Snowball Edge に IAM を導入する前まで、IT 管理者はファイルをコピーしたり、コンピューティングワークロードを実行したりするユーザー全員と、単一のアクセスキー/シークレットキーの組み合わせを共有していました。このアクセス方法は、個々のサービスを制御できるほどの詳細度と柔軟性を持ち合わせていませんでした。IAM では、ユーザーが実行できるアクションを制御することにより、Snowball Edge デバイスで実行されている AWS サービスおよびリソースへのアクセスを安全に管理できます。IAM を使用すれば、デバイスユーザーがアクションを実行するために使用するデバイス上のどの AWS リソースも管理することができます。このブログでは、Snowball Edge での IAM 機能を探索し、いくつかの実用的な例を示しています。 概要 Snowball Edge を使用すれば、インターネットへの接続が選択肢にない場所でも、AWS クラウドのストレージとコンピューティングパワーにローカルで費用対効果の高い方法でアクセスできます。オンプレミスのデータセンターと Amazon Simple Storage Service (Amazon S3) の間で数百テラバイトまたはペタバイトのデータを転送できます。さらに、Snowball Edge は特定の Amazon EC2 インスタンスタイプと AWS Lambda 関数を実行する機能を提供するため、オンプレミスまたはクラウドで開発されたアプリケーションを同じデバイスにデプロイできます。Snowball Edge の一般的な使用例には、データ移行、データ転送、データ分析、画像照合、IoT […]

Read More

新機能 – 拡張された Amazon Macie が大幅に値下げされた料金で利用可能に

Amazon Macie は、機械学習を使用してデータを自動的に特定および分類することで、機密データを検出して保護するのに役立つフルマネージド型のサービスです。 お客様に Macie を長期にわたってご利用いただく中で、お気に入りの点とそうではない点を伺いました。 サービスチームはこのフィードバックに対処するために一生懸命取り組んできました。そして本日、Amazon Macie の拡張された新しいバージョンをご利用いただけるようになったことをお知らせします。 この新しいバージョンでは、料金プランがシンプルになっています。評価される Amazon Simple Storage Service (S3) バケットの数と、機密データ検出ジョブで処理されるデータの量に基づいて請求されるようになりました。新しい段階的な料金プランは、料金を 80% 引き下げるものです。さらにボリュームが大きい場合は、90% 超のコストを削減できます。 多くの新機能も同時に導入されています。 個人識別情報 (PII) を検出するための更新された機械学習モデルを含む強化された機密データの検出、および正規表現を使用したお客様が定義する機密データタイプ。 AWS Organizations でのマルチアカウントのサポート。 AWS SDK および AWS コマンドラインインターフェイス (CLI) でサービスをプログラムで使用するための完全な API カバレッジ。 リージョンの可用性を 17 のリージョンまで拡大。 開始とコストの理解に資する、シンプルになった新しい無料利用枠と無料試用版。 完全に再設計されたコンソールとユーザーエクスペリエンス。 Macie はバックエンドで S3 と緊密に統合され、より多くのメリットを提供します。 AWS CloudTrail で S3 データイベントを有効にすることは要件ではなくなり、全体的なコストがさらに削減されます。 すべてのバケットの継続的な評価が行われ、パブリックバケット、暗号化されていないバケット、および Organization 外の AWS アカウントと共有 (またはレプリケート) されたバケットのセキュリティの検出結果が発行されます。 […]

Read More

Amazon Forecast: 学習済み Predictor を再利用して最新の予測を更新する

こんにちは、アマゾン ウェブ サービス ジャパンの藤田です。Amazon Forecastでは、過去の時系列データからpredictor(予測子)の学習を行い、将来(新しいデータポイント)の予測を行うことが可能です。需要予測や在庫計画など、様々なビジネス課題に適用することができます。今回は、Amazon Forecast で学習した Predictor を再利用して、最新の予測を更新していく Rolling Forecastについて紹介します。

Read More
SharedResponsibilityModel

責任共有モデルとは何か、を改めて考える

本Blogは、クラウドにおける新しい常識”new normal”を考えるBlogの第二弾です。(第一弾「クラウドにおける安全なデータの廃棄」はこちら) 今回は、クラウドの基本的な考え方である”責任共有モデル”をとりあげます。こちらのBlogをご覧の皆様の中には”何故、いまだに責任共有モデルなのか”という疑問を持つ方もいらっしゃるかもしれません。しかし、未だに本モデルの考え方や実際のビジネスへの適用方法は十分に理解されていないようにも見受けられます。今回は責任共有モデルとは何か?を振り返るとともに、いくつかの理解のポイントをお伝えします。 セキュリティ責任共有モデルとは? ”セキュリティとコンプライアンスはAWSとお客様の間で共有される責任です。この共有モデルは、AWSがホストオペレーティングシステムと仮想化レイヤーから、サービスが運用されている施設の物理的なセキュリティに至るまでの要素をAWSが運用、管理、および制御することから、お客様の運用上の負担を軽減するために役立ちます。お客様には、ゲストオペレーティングシステム (更新とセキュリティパッチを含む)、その他の関連アプリケーションソフトウェア、およびAWSが提供するセキュリティグループファイアウォールの設定に対する責任と管理を担っていただきます。使用するサービス、それらのサービスの IT 環境への統合、および適用される法律と規制によって責任が異なるため、お客様は選択したサービスを慎重に検討する必要があります。また、この責任共有モデルの性質によって柔軟性が得られ、お客様がデプロイを統制できます。以下の図に示すように、この責任の相違は通常クラウド ’の’ セキュリティ(Security ‘of’ the Cloud)、およびクラウド ’における’ セキュリティ(Security ‘in’ the cloud)と呼ばれます。” 責任共有モデルを踏まえたセキュリティ効率性の改善 責任共有モデルを適用するうえでのメリットを考えてみましょう。例えばお客様がPCI DSS等の認証の取得を考えた場合、全ての要件を自社で管理を行うことは非常に負荷が高く、コストもかかる作業となります。AWSはPCI DSSを含めた様々なコンプライアンスプログラムや第三者認証に取り組んでおり、お客様は自らの認証の範囲からデーターセンターの物理的な統制を除外することができます。お客様はAWS Artifactからリポートを入手することで、物理統制の評価が可能となります。この場合、認証の範囲を縮小することは審査だけでなく運用上の負荷においても大きな便益をお客様にもたらします。 同様にAWSのサービスを考えた場合、Amazon EC2インスタンスにサービスを構築する場合と、Amazon RDSなどのマネージドサービスやAWS Lambdaなどのサーバレスアーキテクチャを活用してサービスを構築した場合では、パッチの適用やバックアップ管理等、セキュリティに関連する負荷は大きく異なります。サービス自体やセキュリティ管理策に対する運用の経済性を考えた場合、AWSにセキュリティ管理を任せることで、お客様はその分の投資をサービスの改善やより重要なワークロードに振り分けることができることになります。つまり、組織がガバナンス上で何を重要とするかといった考え方に基づき、選択肢を持つことが可能となります。 AWSは”クラウド内のセキュリティに対する責任”を助けないのか。 上記のモデル図で考えた場合、責任の分界点として、”ユーザのセキュリティに対してAWSは何もしてくれないのか”という疑問をもたれるケースがあります。もちろん、そうではありません。AWSは様々な手段でお客様のセキュリティの実現を支援します。第一に、AWSは豊富なセキュリティサービスや機能、アップデートを提供しています。AWSにおける脆弱性の発見等はセキュリティ速報に公開され、お客様はRSSフィードで購読することが可能です。これらにより、お客様は自らのニーズにあったセキュリティの実装や対応を行うことができます。次に、開発者ガイドや各種ホワイトペーパーなどをもとにお客様のセキュリティに対して必要な情報を提供しています。また、単に設定方法を伝えるだけではなく、Well Architectedフレームワークは、クラウドの特性を活かしたサービスの原則を提供することで、お客様のセキュリティを支援する道具になります。 また、支援は機能やサービスだけではありません。AWSではSolution Architectによる技術支援やProfessional Servicesによる有償コンサルティングサービスの提供、Certification and Training teamによるトレーニングサービスの提供、AWS Supportによるお客様課題の支援や対応窓口の提供など、様々な形での組織的な支援を行っています。例えばAWS Supportではナレッジセンターとしてお客様からのお問い合わせの頻度の多い質問に対する回答を公開しています。 また、お客様がコンプライアンスに準拠した環境でサービスを設計、運用するためには、実際の構築や運用の担い手となるパートナー様の尽力が不可欠です。政府機関における「政府機関等の情報セキュリティ対策のための統一基準群」に対するリファレンスや金融業界における「FISC安全対策基準」へのリファレンス等は、AWSJの協力に基づきAPNパートナー様により開発、公開されており、システムインテグレーターや開発、運用事業者はこれらを活用することが出来ます。 このようにAWSは組織的、技術的に様々なアプローチでお客様のセキュリティをサポートする手段を提供しています。 多くの”責任共有モデル”は二階層ではない。 上記のモデル図は”AWS”と”お客様”の二階層で責任共有を表現しています。しかし、様々な場合において、二階層で責任共有モデルを考えることは現実的ではないことがあります。例えば、日本では多くの調達や開発、運用において、システムインテグレーターや開発、運用事業者が存在する場合がありますし、例えばお客様がSaaS事業者と契約した場合、そのインフラストラクチャをAWSが提供している場合があります。こうした場合、セキュリティは重層的になります。実際にはお客様の中でも様々な責任共有の形があります。また、お客様の中にも責任共有モデルは存在します。事業部門とシステム部門、監査やリスク管理部門など、単一の組織においてもセキュリティの責任は複数の組織で共有しているものとなります。責任の範囲を明確にすることは本来は自然なことであり、まずは範囲を明らかにした上で、どのように協働をおこなうかというプロセスが重要になります。 重層的な責任共有モデルにどう向き合うか お客様がSaaS事業者やシステムインテグレーターと契約した場合、セキュリティに対する説明責任はそのような事業者自身がAWSが提供する様々な情報を活用してお客様と向き合うとともにセキュリティの実装などに責任を持つことになります。こうしたパートナー様のエコシステムの育成や拡充のために、APNパートナープログラムではセキュリティコンピテンシーやパブリックセクターコンピテンシー等、お客様が業界や技術に明るいパートナーを選択できる仕組みを提供しています。既にご説明したAPNパートナー様によるセキュリティリファレンスなどの取り組みも進展しています。また、お客様の中における責任共有モデルにおいても、AWSでは実際にお客様の様々なクラウド移行を支援してきた経験から、お客様内におけるクラウド推進組織であるCloud Center of Excellence (CCoE)の設立などをベストプラクティスとしてお客様にお伝えしています。 責任共有モデルは”セキュリティだけ”のものではない。 このような責任共有という考え方は、”セキュリティだけ”に適用されるものではありません。例えば、ある情報システムのクラウド移行を想定した場合にも、“移行計画”の策定、“予算”の見積もりと確保、“クラウド要件”の定義、“調達/購買”の実施、(特に公共部門の場合には)“契約”の締結、実際の“精算”・・といった一連のプロセスが伴います。ここで注目すべきは、ユーザ側・調達者側が上記の一連のプロセスにおいてガバナンスを強化することが望ましい「new normal」においては、従来のモデルとは責任主体や責任の共有の仕方が異なるケースが頻発する、ということです。例えば:  “予算”の見積もりと確保──クラウドのコストメリットは、従量課金により実際に使った分だけを支払うことができる点に求められます。旧来の情報システムの発注は、その運用までも含め、固定額で見積もられることがほとんどでした。しかしクラウドを前提とした予算の確保では、ユーザ側・調達者側が積極的にクラウド利用料金の実績値管理(その頻度は週次であったり、日次で行うことも可能です)に主体性を持ち、次年度(場合によっては次期四半期)の予算確保の精度を継続的に上げていくことが求められます。ツールとしてはAWS Cost Explorer等が役立つはずです。 “調達/購買”の実施──旧来の情報システムの“調達/購買”においては、システム・インテグレーター(SI)によってシステム構成要件の全てを満たすことが期待されていました。しかしクラウドを前提とした調達/購買においては、これらの要件をSI/AWS/調達者の三者(あるいは、リセラーを含めた四者)によって分担し、共有することが必要となります。SIに求めるべきことをクラウドサービス事業者に求めるべきではなく、その逆もまた然りであるため、両者には別途独立した要件を求めることが妥当です。 […]

Read More