Category: Best Practices

本投稿はワールドワイドで金融業界を担当しているプリンシパル・テクニカルプログラムマネージャーの Jennifer Code による寄稿を翻訳したものです。 私の同僚の Ilya Epshteyn が、 金融機関が機密性の高いデータのためにAWSサービスを承認する方法 というタイトルのブログでご紹介したように、金融業界では一般的にクラウドサービスの正式な評価プロセスが存在します。これらの評価プロセスは深さや幅に関しては様々ですが、いずれのプロセスも、業界の期待とテクノロジーリスク管理の健全性を確保しつつ、ビジネス要件を満たすのにはどのクラウドサービスが最適かを決定しようとするものです。このブログでは、クラウドサービスに対する新たな評価プロセスを構築する、または既存の評価プロセスを最適化する際に役立つシンプルなガイダンスを提供します。 私は、お客様と頻繁に会ってお客様のガバナンスとクラウドの評価プロセスについてディスカッションをしますが、その中でよく耳にするテーマがいくつかあります。１つ目は、評価プロセスが正式に存在する場合であっても、オーナー不在の場合が多く、結果としてそのプロセスが達成すべきビジネス上の成果を必ずしも理解しないまま、チームがプロセスに従っているという問題です。強いオーナーシップがなければ、参加者と評価範囲に一貫性が保てません。また、時には、構造化されたフレームワークではなく、個々の専門知識とベストエフォートに依存しているため機能性に差異が生じている場合もあります。最後に、お客様は、ほとんど例外なく、知識の共有を進めつつ、繰り返し学ぶことによって、評価プロセスの質を一気に向上させる方法があるのではと感じています。 正式なクラウドサービス評価プロセスがとても重要なのはなぜでしょうか? 金融サービス会社は、テクノロジーリスクの監視を証明するという、共通の規制上の義務を負っています。従来、企業のリスクフレームワークは、サイロ化された「3 つのラインによる防御」または (3LoD) で構成されていました。第一のラインはリスクの所有者としてコントロールを実行するビジネス / 運用担当者、第二のラインはリスクのモニタリングとコントロールの評価を行うリスク管理担当者、第三のラインは独立または内部監査人、またはリスクアシュランス担当者で構成されています。これらの 3LoD はそれぞれ、テクノロジーリスク、一般的な社内のポリシーの収集、ならびに他の防御ラインによって行われた一連の評価・監査に合わせて自チーム内で文書化された手順についての責任を負ってきました。 この既存の企業リスクフレームワークにクラウドの評価プロセスを組み込むことで、組織は重要な技術上の意思決定がどのように行われたかを適切に証明できるようになります。また、リスクがどのように評価され、軽減されるか、コントロール環境の強さがリスクアペタイトにどのように適合しているかといった点を、クラウドベースのサービスの微妙な差異に焦点を当てつつ説明できるようになります。 クラウド評価を最適化するためのヒント 金融サービスのお客様の期待を念頭に置き、お客様がクラウド評価プロセスを構築または改善するために実行できる3つのアクションを提案します。 ガバナンス体制の正式化。ガバナンス体制が正式に確立されていない場合、金融サービス機関がとるべき最初のステップは、クラウドのガバナンスとコントロールに関してエンドツーエンドの責任を担うC-レベルの経営幹部を任命することです。 プラットフォーム コントロールの優先順位付け。クラウド評価を策定する際に、優先順位と要件について、クラウド・プラットフォームとビジネス・アプリケーション機能の区分を取り入れます。セキュリティとレジリエンスのためのプラットフォームレベルのコントロールを最初の優先事項として重要視します。ビジネス・アプリケーションの機能に視点が移った時に、クラウドプラットフォームから継承されたコントロールに基づいて評価を調整できるようになります。 継続的な改善の組み込み。 知識共有と継続的な改善は、Day 1から明確に優先されるべきです。積極的な透明性があることにより、コントロールが構築され評価が行われる際に、3つの防御ラインすべてにわたっての信頼が築かれることが期待されます。意識的かつ積極的な共有によって、コントロールが設計されており、最初の本番ユースケースに対しても効率的に実行することができるという自信につながります。 AWSの使用量と専門知識が増えるにつれて、コントロールの強化と適用範囲の継続的な改善も容易になります。 ガバナンス体制の正式化 重要な最初のステップはクラウドのガバナンスに対する完全な説明責任を持つ適切な Cレベルの経営幹部を特定することです。この個人は、はじめにクラウドのガバナンスとコントロールのトーン設定を行い − クラウドの評価、使用状況、および継続的なモニタリングのための構造とプロセスを構築する責任をもちます。重要なのは、組織全体の専門知識を活用して、十分に制御されながらアジリティのある環境を確立するよう促す意欲のある、強力でポジションの高いリーダーを任命することです。 そのガバナンスのリーダーは任命され次第、評価プロセスを形成する機能横断的な構造、成文化されたポリシーと必要となるガバナンスプロセスを正式化し、現在進行中の評価のサポートをしなくてはなりません。私の経験では、正式なガバナンスの枠組みに支えられた多様な専門知識を活用できるバーチャルなチームが最も効果的です。 効果的なクラウドガバナンスの考慮事項 効果的なクラウドガバナンスの目標を定め、専門知識を正当に評価する企業全体のクラウド戦略 は、導入と使用状況を測定しながら時間をかけて構築します。 クラウドガバナンスに責任のある経営幹部を任命、従事、およびコミットすることで全体的なガバナンス構造に統合し、継続的なモニタリングを行います。 知識が豊富で 参加を約束できる（3 つの防御ラインにまたがった）リスクとコントロールのステークホルダーをクラウドのガバナンス活動における正式な参加者 にします。 企業のガバナンス フレームワークとプロセスに準拠することで、クラウドイネーブルメントチームの存在を明確にします。 定義されたプロセスを組織に伝達するとともに、承認されたクラウドサービスのみを利用していることを確実にする自動強制機能を使用します。 プラットフォーム コントロールの優先順位付け 私と顧客とのやり取りでよく見られたパターンは、クラウドサービスを評価するにあたり、たった１つのアプローチを作成し、それを全てのパターンに当てはめようとするやり方です。これは典型的に、各サービスを個別に評価する形式をとり、多くの場合、体系的に完成された詳細なチェックリストを伴います。 なぜこれが理想的ではないのでしょうか? 第一に、これは各サービスへの脅威は同等であることを前提としています（したがって、同じ評価が必要なコントロールを決定する適切な方法とされます）。第二に、このタイプのアプローチでは、評価者が能力または機能により区別することは認めていません（たとえば、データを中心としたサービスとコンピューティング サービスの違いを考慮しません）。最も重要な点は、既存の統制基盤を考慮していないことです（したがって、追加のコントロールの必要性を過大評価してしまう可能性があります）。 私が見てきた中で最も効果的だったのは、交渉不可能な基盤を確立した上で、環境、データの機密性、ビジネスの重要性など、他の要因に基づいて必要なコントロールを追加する、段階的なコントロール フレームワークです。この区分けによって、不適切なレベルのリスクを発生させることなく、実験を行うことができます。具体的には、すべてのデータタイプ、すべての環境において最初から予防的統制でなければならないコントロールもありますが、その他のコントロールではモニタリングをサポートすることによって、発見的統制から始めることが許容できるかもしれません。適切にコントロールされたイノベーションが目標です。 […]

スポットインスタンススペシャリスト ソリューションアーキテクトの滝口です。2020年6月10日にオンラインで開催された「コンテナ × スポットインスタンス」 活用セミナーでは、200名を超えるご参加人数という大盛況のもと、AWSのソリューションアーキテクトによる技術解説と、各種コンテナ技術を最大限に活用してスポットインスタンスをご利用いただいている3社のお客様から、実際の事例についてお話いただきました。 本記事では、お客様のご登壇資料を含む当日資料のご紹介、また参加者の皆様からいただいた当日のQ&Aの一部をご紹介します。 当日アジェンダと資料 12:00～13:00　Amazon EC2 Auto Scaling によるスポットインスタンス活用講座 講師：滝口　開資（アマゾン ウェブ サービス ジャパン株式会社　ソリューション アーキテクト） Amazon EC2 Auto Scaling によるスポットインスタンス活用講座 13:00～14:00　具体的実装に学ぶ、Amazon ECS × EC2 スポットインスタンス、Amazon EKS × EC2 スポットインスタンスによる低コスト & 高可用アーキテクチャ 講師：Hara Tori（アマゾン ウェブ サービス ジャパン株式会社　シニアデベロッパー アドボケイト） Containers + EC2 Spot: 特性と実装パターンに学ぶ低コスト & 高可用アーキテクチャ / Practical Guide for Amazon EC2 Spot with Containers […]

このブログは、認知科学の原則を使って AWS クラウドの学習効果を高める方法に関するシリーズ記事の第 3 回（最終回）です。 このシリーズの前回と前々回では、プレゼンテーションや講義からの情報を受動的にインプットすることばかりに依存しないということが、いかに重要であるかについてを取り上げました。長期的な学習効果を強化していくためにはインプットばかりでなく、その情報を能動的に 記憶から引き出す（または思い出す） よう、セルフテストに挑戦することが大切です。またこの考え方をふまえ、 時間間隔を空けた反復学習 を実践することで、学習をより効率的かつ効果的にする方法についてもご紹介しました。 どちらの戦略でも強調されているのは、学習プロセスにおいては記憶が重要な役割を果たすということです。ある分野についてのプロフェッショナルになるためには、その分野に関する主要な概念や事実といった強固な基礎を身につけることから始める必要があります。たとえば機械学習 (Machine Learnning: ML) について言えば、そもそも特徴量エンジニアリングとは何かを知らなければ、ML モデルで特徴量エンジニアリングを実践することは不可能です。 しかしこれまでに説明してきたことを鑑みると、キーとなる情報を記憶するためにいたずらに反復学習を行うことが正しいとは限りません。情報に対する理解を深めるのに役立つテクニックがいくつかあります。そのうちの 1 つはエラボレーションと呼ばれるものです。 エラボレーションとは エラボレーションとは、学習中の新しい情報を既存の知識と関連付けていくことで、新たにインプットしている情報に詳細を付け加えていくプロセスのことです。エラボレーションのプロセスでは What (何を) 学習しているかよりも、学習中のトピックの背後にある How (どのように) や Why (なぜ) により重きを置きます。ここでは簡単な例を使って、この概念をより具体的につかんでいきましょう。 エラボレーションの実践 機械学習を例にとった場合、おそらく最初に直面するハードルの 1 つは、この分野特有の用語や概念についての語彙を理解することでしょう。そのためまず Demystifying AI/ML/DL や What is Machine Learning? といったトレーニングを受講し、そこに出てくる用語や概念について時間差学習によって小刻みにセルフテストを行います。 機械学習のタイプの違いを理解しているかを確認するセルフテストの問題の 1 つとして、たとえば以下のような問題があったとします（正解は1）。 次のうち、教師あり学習が最も適しているのはどれか答えなさい 画像内の鳥を特定する 購買傾向に基づいてある集団をより小さな集団にグループ化する データセット内の特徴量の数を減らす クレジットカード取引データ内の異常を特定し、不正としてラベル付けする この問題やその他の同様の問題に正解することはさほど難しくありません。つつまり、回答にあたって教師あり学習ついて深い理解が必要な問題とは言えません。フォローアップの問題に挑戦することでエラボレーション、つまりこのトピックに関する詳細を付け加えていきます。こうすることで、より深い理解が得られます。 以下に示すのは、この状況またはその他の同様の状況でフォローアップエラボレーションとして活用できる問題の例です。 「画像内の鳥の特定」が、どのように教師あり学習の良い例であるか説明しなさい 他の選択肢が、教師あり学習に適していないのはなぜですか 正解の選択肢に加えて、教師あり学習の適切なユースケースを他に挙げなさい 正解の選択肢が、教師なし学習の例でないのはなぜですか   エラボレーションが脳に与えるインパクト エラボレーションの問題が学習に大きな効果をもたらすメカニズムは、脳が情報を最も効果的に保存および取り出す仕組みと関連しています。長期的な観点では、脳内にある他の情報と密接に接続された情報（大きく強固に張りめぐらされたクモの巣状のニューロンをイメージしてください）は、そうでない情報、つまり他の情報との関連付けが乏しく接続の弱い状態で保存された場合と比べて、はるかに簡単に記憶から取り出せるようになります。エラボレーションの問題に取り組み、学習中のトピックに詳細を付け加える訓練を実践すると、先に述べたニューロン同士の密接な結合の形成につながります。 では、この エラボレーション の原則を AWS クラウドの学習に活用するにはどうしたらよいでしょうか。以下にいくつかのアイデアを示します。 フォローアップ問題に挑戦する。反復学習 (小テストの問題に解答する、メモカードでセルフテストをする、難しい ハンズオンラボ […]

本記事は、EC2スポットインスタンススペシャリスト シニアソリューションアーキテクトのIsaac Vallhonratによる寄稿です。 Amazon EC2 スポットインスタンスを使うと、AWS クラウド内の使用されていない EC2 キャパシティーを用いて、オンデマンド料金に比べ最大 90% の割引価格でご利用いただけます。スポットインスタンスは、バッチジョブ、ビルド等のCI/CDパイプライン、負荷テスト、コンテナ化されたワークロード、ウェブアプリケーション、ビッグデータの分析クラスター、ハイパフォーマンスコンピューティング(HPC)用計算クラスターなど、複数のインスタンスタイプで柔軟に実行できる、耐障害性を備えたワークロードに最適です。このブログ投稿では、スポットインスタンスでウェブアプリケーションを実行するための方法とベストプラクティスについて説明し、これによりもたらされるスケールと費用節減の両方のメリットを得られるようにします。 スポットインスタンスには中断という特徴があります。この特徴を踏まえて、これから構築するウェブアプリケーションはステートレスかつ耐障害性があり、また疎結合されていることが望ましいです。また永続データの保持には Amazon ElastiCache, AmazonRDS, Amazon DynamoDB などの外部データストアを使用する必要があります。 スポットインスタンスのおさらい 2009 年に提供開始されたスポットインスタンスは、ここ最近のアップデートや関連サービスとの統合によって、お使いのワークロードで格段に活用しやすくなっています。ウェブアプリケーションを構築する方法の詳細に入る前に、スポットインスタンスの動作の概要のおさらいにお付き合いください。 まず、スポットインスタンスは EC2 の購入オプション、買い方のひとつです。 他の購入オプションである、オンデマンドインスタンス、リザーブドインスタンスやSavings Plansで起動した場合と比べて、EC2インスタンスとして提供するハードウェアに違いはありません。スポットインスタンスと他の購入オプションの違いはただ一つ、EC2 サービスが容量を必要とする場合には、2 分前に通知したのち、EC2サービスがスポットインスタンスを中断する、という動作です。つまり、大幅な割引価格で提供する代わりに、オンデマンドインスタンスやリザーブドインスタンスからの起動需要が高まってきたとき、スポットインスタンスの使用していたキャパシティをEC2サービスに戻し、需要に応える、というのがスポットインスタンスサービスの動作原理です。 スポットインスタンスは、スポットキャパシティプールと呼ばれる、いわば空きキャパシティがある限り起動できます。スポットキャパシティプール(スポットプール)とは、とは、インスタンスタイプ (m5.large など), オペレーティングシステム種別(Linuxなど), アベイラビリティーゾーン (us-east-1a など) が同一である、Amazon EC2 サービスが使用していない（空の） EC2 インスタンスの集合を指します。属性の異なるプール同士はそれぞれ独立したプールとして区別されます。例えば、us-east-1aゾーンのLinux向けm5.largeのスポットプールと、us-east-1bゾーンのLinux向けm5.largeのスポットプールは、独立した別のプールです。このそれぞれに空きがあるとき、スポットインスタンスを起動し、使用できます。 スポットインスタンスの料金は Amazon EC2 サービスによって設定され、各プールの EC2 インスタンスの需要と供給の長期的な傾向に基づき、徐々に調整されます。スポット料金は急激に変化することはなく、突然のスパイクや変動がないことが期待できます。 EC2 マネジメントコンソールと API の両方から、最大過去 3 か月間の価格履歴データを表示できます。次の図は、バージニア北部 (us-east-1) リージョンにおける m5.xlarge […]

このブログは、認知科学の原則を使って AWS クラウドの学習効果を高める方法に関するシリーズ記事の第 2 回です。 シリーズの第 1 回では、長期学習における反復学習の重要性について取り上げました。学習にあたっては数百のアマゾン ウェブ サービス (AWS) のサービスや機能に充分に留意しておく必要があります。すべてをより効果的に学習するには、ビデオを観たりドキュメントを読んだりして情報を受動的にインプットするだけでは不充分です。クイズやメモカードを使った学習、 ラボなどのハンズオンアクティビティを通したセルフテストを実行することで、学習中の情報を能動的に活用して、記憶から引き出す必要があります。 しかし多くの場合、多忙なスケジュールの中で継続的に反復学習を行っていくのは簡単ではありません。そこで有用なのが、時間差学習 (Spaced Practice) という概念です。 時間差学習とは、ある一定の期間中に徐々に時間間隔を広げて学習時間を分散させるというやり方です。     たとえば今週初めに視聴した Amazon S3 に関するビデオの内容に合わせて自身で作成したメモカードを確認するとします。メモカードでの学習にかかる総時間は約 60 分です。時間差学習ではこの時間を複数回に分散させることで、60 分間かけてすべてを 1 回で学習するよりもはるかに高い長期的学習効果を得ようとします。 この場合にカギとなるのは、覚えようとしている情報が記憶から消えてしまうギリギリのタイミングで復習を行うことです。このスイートスポットは人それぞれで異なります。 いずれにしても、学習中の情報が脳内の長期記憶に関連する部分に統合されるまでには時間が必要です。脳内からその情報を取り出すタイミングを遅らせる（または間隔を空ける）と、その情報は長期記憶を司るニューラルネットワークへより強く取り込まれます。間隔を空けずに行う反復学習は、この記憶の取り込みに要する時間を考慮しておらず、結果的に学習内容が短期記憶の範疇にとどまりやすくなります。   間隔を空けた反復学習は、長期記憶を格納する脳の領域に統合した後、記憶痕跡を活性化します。内側側頭葉は短期的な記憶を保存します。大脳新皮質は長期的な記憶を保存します。   Amazon S3 ビデオの例に戻りましょう。ビデオを見た直後に聞いたことをセルフテストすると、質問に回答する際には短期記憶の中から情報を引き出していることになります。情報を長期記憶に取り込むのに十分な時間がなかったためです。   ラーニングセッションまたはプレゼンテーションの直後に復習を行うと短期記憶が使用される。   時間差学習では、セルフテストを数時間あるいは数日の間隔を空けて行います。この時点で、情報を長期記憶に統合する時間があったことになります。テストへの回答は難しくなりますが、長期的には学習効果に大きな効果をもたらします。   ラーニングセッションまたはプレゼンテーションから間隔をおいて復習を行うと長期記憶が使用される。   では、AWS クラウドの学習に時間差学習を活用するにはどうしたらよいでしょうか。 以下にいくつかのアイデアを示します。 集中詰め込み式をやめ、学習を小さなチャンクに切り分ける。 1 週間休むことなく勉強すると短期的には有効に感じられるかもしれませんが、長期的には学習効果が低くなってしまいます。そのかわりに数百におよぶ AWS トレーニングを活用してください。トレーニングの多くはオンラインで受講できるショートトレーニングコースで、これを活用するとインプットからある程度の間隔 (数日間というよりは数週間程度の期間にわたって) をおいて簡単に学習内容を復習できます。 ラーニングパスを選択し、独自の間隔で学習スケジュールを立てる。 AWS のラーニングパスは一連のコースと試験で構成されており、このパスに従って学習を進めることで AWS […]

アマゾン ウェブ サービス (AWS) の 175 を超えるサービス群、数百にもおよぶ機能、クラウドコンピューティングの用語や概念という新しい語彙。これらは AWS の構築を学ぼうとする際に最初の壁となり立ちはだかります。この壁は多少険しいものに感じられるかもしれません。また、情報を受動的にインプットする学習法にばかり頼っていると、壁を乗り越えるのは難しくなってしまいます。 一方でこの障壁の高さを引き下げて、 AWS ビルダーとしての学習目標の達成を支援してくれるものもあります。人間にとって最も効果的な学習方法に関する、数十年にわたる研究から得られた認知科学的な知見、そして 数百に及ぶ AWS トレーニングポートフォリオ を活用できることです。 これからシリーズブログとして、数回にわたってこのテーマを扱っていきます。シリーズ内の各記事では、AWS のサービス、機能、および関連する概念をより効果的に学習し、結果としてより優れたビルダーになるために活用できる認知科学の原則に焦点を当てていきます。このシリーズでは次のテーマに基づいて概説していきます。 反復学習 時間差学習 エラボレーション   シリーズ第 1 弾となる今回は、反復学習についてご紹介しましょう。 反復学習の原則とは、学習者が以前に見たり聞いたりした情報を定期的に記憶から取り出して、その情報を使用して問題を解決したり質問に回答したりすることで、長期学習が強化されることと規定されています。 つまり反復学習とは、自分の記憶から情報を引き出す機会を学習者が自分自身に与えることです。 これは情報のインプットのみに重点を置いた、前述のアプローチとはまったく対照的です。学習した情報を保存するニューラルネットワークはその情報を繰り返し受動的に取り込むのではなく、自分の力で情報を思い出す（または記憶から取り出す）ことで強化されます。   通俗的な学習方法においては情報のインプットに重点を置く傾向がありますが、脳の学習方法に関する研究では、(反復: Retrieval により) 情報の取り出しを行うことが長期学習に不可欠であることがわかっています。   簡単な例を見てみましょう。2 つのグループがあります。どちらのグループも、Amazon S3 に関するプレゼンテーションに参加しました。それ以降 2 週間にわたり、1 つ目のグループ (反復学習グループ (Retrieval Group)：RG) のメンバーは、参加したプレゼンテーションで紹介された主な概念やトピックを思い出せるかどうかを試す一連のクイズに参加します。 一方で 2 つ目のグループ (非反復学習グループ (Non-Retrieval Group)：NRG) のメンバーは、プレゼンテーションで紹介され主な概念とトピックを繰り返す、一連のフォローアッププレゼンテーションに参加します。RG とは異なり学んだ情報に関するクイズやテストは受けません。 最初のプレゼンテーションから数週間さらには数か月後、RG は Amazon S3 に関連する記憶の保持に関して […]

ビジネスリーダーやテクノロジーリーダーと話すと、彼らは新しい製品やサービスを迅速に市場に投入することが必要だと話します。その一方で、彼らはセキュリティを継続的に確保する必要もあります。また同時に、時間とともに変化するビジネスニーズにワークロードを適応させながら、回復力のある環境を維持する必要があります。このブログシリーズでは、AWSのベストプラクティスを共有して、お客様がこれらのセキュリティ、スケーラビリティ、および適応性の要件を満たすようにAWS環境を計画するのを支援します。 私の目標は、クラウド環境の配備を管理するための設計上の考慮事項についてお客様をガイドすることです。このブログシリーズでは、今後、このガイダンスに沿った一般的なユースケースとパターンの実装を解説するブログを投稿していきます。