0:00 それでは時間となりましたので、トレーニングを始めていきます。皆さん、 おはようございます。
0:07 本日はエーアイレディーインフラクラウド提案のための一日集中トレーニングにご参加いただき、誠にありがとうございます。今回講師を務めます、株式会社スキルアップネクストよいきました森田と申します。どうぞよろしくお願いいたします。本日のトレーニングでは。
0:27 今後のデータ活用、そしてAI活用を支えていくAzureインフラについて、 一日で集中して学んでいきたいと思っています。こちらが本日のスケジュールです。
0:40 午前はAzureインフラストラクチャーをテーマに、なぜクラウドなのか、 なぜAzureなのかということについてしっかり学んでいきます。
0:55 午後からは、 セキュリティとデータベースというエーアイレディーの環境に不可欠な二つの要素についてしっかり学んでいきたいと思っています。お昼休憩が12時から13時ですね。こちら一時間となっております。午前と午後二つに分かれています。今回の講座はですね、夕方の17時半までとなっており。
1:20 やや長丁場かなと思いますが、適宜休憩を挟みながら進めていきますので、 皆さんどうぞ最後までよろしくお願いいたします。
1:32 ここで簡単に弊社スキラップネクストについてご紹介をさせていただければと思っております。私たちスキラップネクストは組織人材変革を加速するAI DXパートナーとして。
1:49 企業のaidx推進を支援しております。aidx歴の人材育成や組織開発、 伴走支援サービスであるスキルアップAI。こちらを中心にしながら、AI開発や導入支援、
2:06 先端領域に特化した人材紹介など、組織人材変革を加速するaidxパートナーとして。
2:16 業界業種問わず様々な企業様をご支援させていただいております。右下の方をご覧ください。 弊社のですね組織人材比較ロードマップとなっておりますが、
2:28 スキルアップAIというサービスの体系を表したものです。人材育成の計画策定から、 編集プログラムの実施、課題解決型の伴走支援とか、AI開発導入支援までですね。
2:42 成果創出のために幅広くサービスを展開させていただいております弊社ですが、 これまでAI百にやDP百といったAzure関連資格講座の開発。
2:57 またAzure環境でのラグ構築の実施。直近ではですねMicrosoft様、 主催のAIチャレンジデイというAI。
3:10 エージェントの構築をテーマとしたコンテキストケースの形式のイベントを行っております。 ここではですね。コンペティションプラットフォームの提供や、
3:22 テーマの企画設計、当日の審査の部分を弊社の方で担当させていただきました。 これらの実績を踏まえまして、本日講義を実施いたします。
3:36 では、ここで、私を含めました本日の講師を紹介させていただきたいと思っております。 本日、データベースのセッションのパートを担当いたします、
3:46 スキルアップネクストの森田と申します。どうぞよろしくお願いいたします。 私はこれまでですね、ウェブアプリケーションの開発とか、
3:56 あとビッグデータプラットフォームの開発、もしくはあの分析業務などですね、 あの従事をしておりました。
4:06 直近ではですね、Azureオープンaサービス、 Azure AIサーチなどを用いた生成AI系のサービスサイズにですね、
4:14 従事していただいております。また、先ほど少し紹介させていただきましたが、 弊社のですね、
4:21 AI 102やDP百といったAzure関連資格講座の開発にも携わっておりました。 今回、皆様がデータベースの知識を実務にですね、
4:30 つなげられるように尽力していきますので、どうぞよろしくお願い致します。
4:38 では、もう一人のですね、講師の紹介をさせていただきたいと思います。ではここで、 弊社のですね、edaの方にバトンタッチさせていただきたいと思います。では、
4:49 入江さんをよろしくお願いいたします。あ、はい。皆さん、どうもはじめまして。 私、株式会社スキルアップネックスト講師の入江と申します。
4:59 どうぞよろしくお願いいたします。
5:02 私は機械学習関連のシステム開発とやっていたんですけれども。 そこでまあ、エムエル関連のいろんなプロジェクトに関わってまいりました、
5:12 最近ではですね、セキュリティに関する取り組みですとか、 こういったものの関心を持ってやらせていただいております。今日は
5:21 どうぞよろしくお願い致します。はい、ありがとうございます。本日はですね、 入江と。
5:28 私、森田の方で進めてまいりますので、皆さん一日どうぞよろしくお願い致します。はい、 ではですね、ここで事務的な確認を二つさせていただきたいと思います。二つですね、
5:39 事務的確認、お付き合いいただければと思います。では一つ目です。はい。 資料のダウンロードについてご案内をさせていただきます。で、今回の講座ですが、
5:50 資料がございます。ぜひですね、お手元の方にご用意いただければと思います。はい。
5:57 スライドに表示されているリンクもしくはキューアールコードから本日の資料意識をダウンロードすることが可能です。はい、またですね。現在ですね。チームズのライブイベントのキューアンドエーというところにも一つ投稿が行われましたので、こちらでも大丈夫です。はい。
6:18 インフラの口座セキュリティ講座、データベース講座、 そして全講座の資料を連結したものこれは四つですね。ご用意しております。まあ、
6:28 皆さんアクセスの観点からあのQAの部分ですね、 アナウンスの部分からリンクを踏んでいただくのがやりやすいかと思いますので、
6:36 ぜひですね、お手元の方にダウンロードの方、よろしくお願いいたします。またですね。 。資料とは別に動画コンテンツも。
6:45 実はございまして、本日の資料を説明している動画コンテンツ、 皆さんダウンロードすることが可能です。まあこちらですね、
6:52 あのリンクの方がございますので、こちらからダウンロードしていただければと思いますが、 全講座分の動画を合わせますと、だいたい9.5時間、
7:01 もう10時間弱ぐらいの動画となっております。しっかりとした内容となっておりますので、 ぜひですね、ご学習の方にお役立ていただければと思っております。はい
7:12 またこちらね。
7:13 。ユーチューブチャンネル、Microsoft、 エーアイクラウドパートナープログラムジャパンの方にも後日アップロードされる予定でございますので、こちらもぜひご確認いただければと思っております。皆さん、お手元の方に白の方はダウンロードできそうでしょうか？
7:29 全講座分の資料がまずあれば大丈夫なんですけども、 午前のパートとしましてはインフラとなりますので、
7:36 まあ一旦インフラの資料がお手元にございましたら、あ、大丈夫かと思います。はい、 皆さんお手元にダウンロードですね。どうぞよろしくお願い致します。はい、
7:46 こちら一つ目ですね、事務的な確認でございました2つ目の事務、 確認させていただければと思います。質問方法についてですね、ご案内させてください。
7:56 今回ご質問ですが、受け付けております。
7:59 チームズライブのQA機能ですね。こちらから投稿いただいて構いませんはい 画面上見ますとQAというパネルがあるかと思いますが、
8:09 そちらの方から質問を投稿いただくことができます。でいただいたご質問ですが、 弊社の方で確認をいたしまして、
8:17 弊社のティーチングアシスタントがチャットにて回答をいたしますので、皆さんですね、 お気軽に投稿いただければと思っております。はい。
8:27 以上で事務的な確認は終了となります。資料のダウンロードよろしくお願い致します。 質問はですね、人物ライブのQA機能から実施することができます。この二点をですね、
8:38 押さえていただければ大丈夫でございます。ではですね、 いよいよ今回のセッションの方にですね、どんどん移っていこうかなと思っておりますが。
8:47 まず今回のですね、全体像について説明できればなと思っております。
8:52 本日の講座のキーワードですが、三つでございます。インフラ、セキュリティ、 そしてデータベースというものですね。昨今、AIやデータ活用というのが、
9:02 やはりこう叫ばれているかなと私は感じておりますが、AIレディー、 AI活用していくためにはですね、
9:09 AI以外の要素も必要不可欠じゃないかと私は思っております。大き*。 *の必要不可欠な要素ためには三つですね、まず一つ目、データベースでございます。
9:22 AIの学習とか、まあ推論に必要なデータをそもそもこう蓄積しないといけませんので、 やっぱりデータを貯める箱であるデータベースはやっぱり大事かなと考えております。でも、
9:33 そういう時じゃダメですね。こうAIとデータがつながるだけじゃダメで、 そもそもそのAIとかデータベースとかが乗っかっている環境ですね。
9:41 それも大事になります。AIサービスを安定的かつ。
9:45 高速に提供するためには、 やはりしっかりとしたインフラ環境が必要なんじゃないかと思います。土台の部分ですね。
9:53 で、土台があればいいのかというと、実はそれだけでは足りない。実はもっとこう、 大前提に相当するような部分がありますね。これはクラウドセキュリティでございます。
10:04 すべての資産、まあ、クラウド上のすべての資産を、 いわゆる脅威というものから守ってくれる、しっかりとしたクラウドセキュリティ。
10:14 これら。
10:15 三つですね。これら三つ、どれが欠けてもやっぱりダメ。 やっぱりすべて揃っているからこそのデータ活用、そしてAI活用って、
10:24 それらの価値がですね、最大化されるか考えております そういったこの三つの要素が相互に連携をして、安全で柔軟なAI活用というのが
10:35 これからの現代では求められていきます。本講座で言えばですね、 このAIを支えていく三つの基盤要素であるインフラ。
10:45 セキュリティ、そしてデータベースですね。 この三つを網羅的に学んでいきたいと思っておりますので、
10:51 皆さんどうぞよろしくお願い致します。では早速とはなりますが、 最初の講座の方に入っていこうと思っております。まず最初の講座ですが、。
11:01 AzureインフラストラクチャーワイクラウドワイAzureと題しまして、 Azureのインフラストラクチャーについてしっかり学んでいきましょう。
11:11 では、ここからバトンタッチさせていただきます。講師の入江さん、 どうぞよろしくお願い致します。はい、かしこまりました。では、
11:21 私の方から画面を共有いたします。
11:44 それではですね、 私の方からAzureインフラストラクチャーワイクラウドワイAzureの口座の方に入らせていただきたいと思います。講師はスキルアップネクスト入江です。どうぞよろしくお願い致します。それではですね、入っていきましょう。あ、最初のページは資料の見方に関するものですので、こちらはスキップいたします。
12:12 それではですね、えっと、この講座の目次について簡単に見ていきましょう。 ポンコツはですね、一章から三章の構成となっております。
12:23 一章オンプレイ運用の課題整理クラウド移行の必要性二章あるAzure上でシステムを動かすには、三章以降とクラウド活用の応用編ということで、進めてまいります。これは三章の関係を確認しておきましょう。
12:43 最初にですね、 オンプレイの課題とクラウド移行のモチベーションにあたるもの確認をしていきます。
12:49 そして次にクラウド移行にあたって必要な基本的な技術要素っていうのを見ていこうと思います。そして三章では、クラウド移行のベストプラクティスを踏まえて移行計画を練っていくという。まあ、プロジェクトの進め方であるとか、いくつかの移行戦略について取り扱っていきます。まあ、移行がメインのテーマであるということですね。クラウドへの移行。
13:14 それではですねえ、もう早速一章から始めてまいりましょう。で、これはですね、えっと、 配布資料の方で、このあたり、用語集などのページ入るんですけれども、
13:23 その分こちらではカットしております。スライドの方、 すぐに進んでいきますが、皆さんの方ではページめくっていただければと思います。
13:36 それではですね。早速、 第一章オンプレ運用の課題整理とクラウド移行の必要性解説を始めていきたいと思います。
13:43 まあ、主にこのタイトルの通り、運用の課題を整理するというところですね。 あのオンプレも別に悪いというわけではないんですけれども、まあ、
13:52 今日のビジネス展開のあり方考えると、 リスクがやはりちょっと大きいということがありますので、
13:58 まあクラウド移行はなぜ必要かというのをここで考えていきたいと思います。
14:05 で、目次ですね。こちらは一旦スキップしまして、概要のページございますので、 こちらで内容を掴んでおきたいと思います。主に三セクションありますね。
14:16 オンプレイの課題。まあ、これはコストと投資の価値に関する内容、 そしてビジネス面での価値と成功パターンと。まあ、この順で見てまいります。
14:27 まあ、とにもかくにもですね、問題がどこにあるのかっていうのをまず把握する。
14:35 そしてその上で、移行がなぜビジネス的にも良いものであるかと。まあ、主にコスト面で、 まあ指標を計算する時の考え方にあたるものを理解していきます。そして、
14:46 実際にどのようにクラウドを活用して成功に至ったのかという事例を紹介していきたいなと思います。まあ、このショーではですね、まあ、顧客がお客様が変える、問題意識に共感できるということ。まあ、これを目標にしていければなと思います。
15:06 ではですね、まずオンプレイの課題について。見ていきたいなと思います。 オンプレイの課題はですね、まあ実際のところ、
15:15 まあ至るところで議論が尽くされているんじゃないかなと思います。で、この説ではですね、 まあそういったものの中から、まあ代表的なものをピックアップしてご紹介いたします。
15:28 例えばですね、このイラストの例なんですけれども、なんかすごいことになってますね、 これはまあ、災害への備えに関する論点を説明したものですね。まあ、
15:39 他にもいろいろあります。一つずつ見ていきましょう。 オンプレ環境が抱えている主な課題これを五つ、ここでは上げております。
15:48 コストの課題でイーオーエスエンドオブサポートですねのリスク、 そしてセキュリティ面の限界。
15:56 で外的要因の変化、そしてビジネスへの影響ですね。これは一つずつ。 見ていきましょう。まず、ポストについてですね、ポストの課題を把握するには、
16:09 まあその種類であるとか、あるいはその組み合わせにあたるものに注目していきます。まあ、 種類で言えば、初期投資初期費用ですね。で、運用コスト、
16:20 まあそれから見えにくいコストといったものがあります。
16:26 コストの内訳？まあ、様々にあるんですけれども、まあオンプレイミスではですね、 特にまあ、初期投資が大きくなりがちですね。まあ、コストが高くなってしまって、
16:36 どうしても何かするってなった場合に、 重大な意思決定が必要になるということになってしまうんです。高いんで。なので、
16:43 ビジネスをどうしてもですね。まあ、 スピーディーに進めづらくなっちゃうというケースも発生します。そうしたら、
16:50 そのスピード感が決意をしてしまうことで、まあ見えづらい隠れたコ。ス。トまあ、 機会損失であるとか
16:56 こういった形でも問題というのが課題というのが現れてくるということになります。で、 特にですね、あのIT機器、これはあの工場の機械と同じ感覚で考えれば、
17:07 ちょっと難しいんですよね。例えば、五年使わないといけないと。 IT機器あったとして五年もあるとですね、まあデバイスの陳腐がすぐに進みますと、
17:17 例えばもうGPUなんてもう信じられないスピードで進化してますよね。
17:23 一方で、あの工場の機械、まあ製造業のお客様とか、まあ工場の機械とかであれば、 まあメンテナンスを続けて、もう十年以上は使えるということもあったりしますと。
17:34 なのでまあ、設備投資における、まあ、こうした性質の違いっていうものをですね、 お客様と認識合わせしておく必要があるんじゃないかなと思います。では次に行きましょう。
17:46 eosディスクエンドオブサポートですね。
17:50 まあ、デバイスやソフトウェアのサポート期限というものもですね。 もういつか切れてしまいます。これも運命です。え、機械だけでなく？まあ、
17:58 ある意味でこの中のソフトに当たるもの、これも古くなっちゃうんですよね。で、 サポートが切れてしまうと、まあ必然的にセキュリティの更新できなくなっちゃいます。
18:08 なので、もうリスクが増大してしまうんですよね。なので、まあ 最終バージョンこれですというのがリリースされた場合に。
18:15 わずか一つでも、まあ攻撃者が脆弱性に見つけてしまえば、 それを使って攻撃することができてしまいます。
18:21 そうするともうこれ事業計測リスク出てきますねですね。 まあサポートが切れますよということがわかっていたら、
18:28 まあ切ればどうしても対応しなければいけないということになります。 これがまあ少し大変な部分もあるんですが、
18:34 一方でまあこのタイミングで対策しなきゃいけないなというタイミングで、 じゃあクラウド移行しましょうかというふうに検。討。されることもあ、るんですね
18:43 え、場合によってはこれチャンスだと捉えることもできるかもしれません。なので、まあ、 これはヒアリングの項目としては結構重要なポイントなんじゃないかなと思います。
18:54 そしてセキュリティ面の限界について。これはですね、もうセキュリティ面。 午後の講座で少し取り上げていくんですけれども、もう日々巧妙化、
19:04 高度化するサイバー攻撃ですね。サイバー攻撃も日々日々高度化しています。で、その場合、 守る側もそれに対応しなければいけないですね。
19:13 そのため、日々インフラ更新続けなきゃいけないということになります。で、 オンプレイの場合は、まあ、ある程度は人材、
19:21 確保するっていうもの課題ではあるんですけど、 ある程度オペレーションアウトソースするとかできるんですけれども、
19:29 まあどうしても限界があるんですよね。で、セキュリティの場合はですね、 もうわずか一つでも脆弱性が残されていたら、インシデントにつながっちゃうんですね。
19:39 なんでもわずかでも気を抜いちゃったら、もう問題が起きてしまうということになります。 ですんで、まあ、セキュリティ対策で脇が甘くなるとしても、まあ必ずまあ、
19:48 企業であればもう訪れてしまうんですけれども、 そのわずかな隙を突かれて重大なインシデントになるということが発生してしまうんですね。
19:57 なんでいつか限界が来るのに、そのわずか隙を突かれてインシデントとなる。これ、 対応するのすごく大変です。毎日毎日メンテナンスしなきゃいけないし、場合によ。
20:06 っては土日も
20:07 出てメンテナンスしなきゃいけないと。これ大変なんですね。なんでまあ、 どうしても限界があるということになります。そして四つの外的要因の変化。
20:21 これは様々ではあるんですけれども、まあ、 ここでは仮想環境の運用の観点とウィンドウズの運用の観点で二つ挙げております。
20:32 一つ目はまあブイエムウェアの買収ですね。
20:37 え、買収されてしまうと、まあ一般的に言って、その製品を提供する企業の、 まあビジネスの舵取りが大きく変わっていきます。まあ、
20:45 この場合はライセンス体系の変更であるとかですね。そうするとまあ、 予想外のコストですね。
20:51 利用者にとっては予想外のコストにつながってしまうということもありえます。 その場合はですね、
20:57 利用者として組んでいた予算があの無効になってしまうんだということも考えられるわけなんですね。
21:03 企業としてはもう毎年毎年予算組んで今年はこれやろうと決めているのに、 その予算がですね、意味なくなってしまうと、
21:12 これはもうあのめちゃくちゃ大きなリスクということになってしまいます。 そして2つ目はですね、ウインドウズサーバーアップデートサービス。
21:22 これの廃止ですね。 まあこのためソフトウェアの更新の考え方というものを見直す必要が生じました。まあ、
21:30 先ほどのページでも。
21:32 まあセキュリティのリスク増大まあ、 サポート終わっちゃいますからということで取り上げてはおりましたけれども、
21:40 それに関連することで、 まあサービスのアップデートまあできなくなっちゃうということが出てきてしまいました。
21:47 ただ、Azureではですね、まあこれらに対して、まあソリューションも ちゃんと用意をしております。で、まあリスクではあるんですけれども、
21:57 まあ対策もあるということにはなってきます。そして最後、ビジネスへ。の影響ですね、 まあこれが。あ、の特に重要かなと思います
22:07 まずですね、あのオンプレのインフラ用意していると、 まあいろいろな制約あるんですけれども、こういった制約があるために、
22:15 まあだいたいその範囲でできることしかできないということになっちゃうんですね。 なんでまあ、ちょっと精神の的ではあるんですけれども、できることしかできないし、
22:25 やらないということになってしまいます。え、 これはあまりビジネスの文脈で言いたくないことなんですよね。
22:32 私はもうできることしかできませんし、やりません。私これできます。 でもこれしかやりません。これなんか、
22:39 ちょっとビジネスとは言いたくないんですよね。 なんかあの成長を捨ててしまってという人の言葉みたいに聞こえてしまうんです、
22:46 あんまりやりたくないと。で、多くの人がああ、 実感していることだとは思うんですけれども、もう昨今、もう技術の進化、
22:53 すごく早いですね。で、特にまあ、AIとか、あるいはまあ最近ね、 流行りのエルエルエムとかですね、こういったもので。あれば半年
23:02 で、場合によってはもう三か月とか、もうそれくらいでもう陳腐化したりとか、 何がいいですっていうの、勢力図が変わったりするということもあるんですね。
23:11 そうすると、まあ、投資判断のための調査とか、まあして じっくり計画練って次やっていこうというふうなプランを練ったとしても、
23:19 プラン練ってる間に次の新技術が公表されてしまうとか、 もうそういうこともありえるんですね。
23:24 とにかくもうスピード感持って対応しなきゃいけないということになります。で。はその
23:29 スピード感ついていくために、あるべき姿って何だろう？ という観点であらゆる施策検討しておくという必要があります。そうなってくると、
23:40 少しずつもうオンプレ環境ってもうどうしても制約としての側面。 どうしても目立ってきてしまうんですよね。というわけで、
23:49 こちら五つ見てまいりました。で、本節のまとめです。 オンプレ環境の典型的課題とリスクということで、まあ五つの課題を見てまいりました。
24:01 まあ、代表的なもの五つですね。じゃあ、ご紹介をしてきました。ではですね、 次に進んでまいりましょう。まあ、
24:11 移行時に注目すべきロイアールオーアイティーシーオーについてまあ主にまあ投資面の話ですね。こちらを見ていきましょう。移行時に注目すべきアールオーアイティーシーオーの言葉、考え方、これら言葉の意味をまず確言していきたいなと思います。
24:35 まあ、こういったものを考える時に、まあクラウド移行ですね、計画する場合は、 まあコストとか数値で示して、まあ必ず比較分析を行うかと思います。
24:44 オンプレイ運用を続けるとこうですね、 クラウド移行するとこうですよというものを必ず比較して提案書出すということになるかなと思います。まあ当然ですけれども、まあ、比較をするということは比較がしやすいもの、すなわち数値できるだけ正確に出すっていうことが大事になります。この流れで、まあコスト計。算。に関する
25:03 まあ、ごく基本的な考え方をここで学んでいきたいなと思います。ではですね、まず、 定番の定量化指標であるアールオーアイとティーシーオーについて見ていきます。で、
25:17 アールオーアイとティーシーオーの定義についてはこちらスライドにあります通りです。 アールオーアイはこれ投資対効果ですね。まあ計算例も、
25:29 こちら記載はしているんですけれども、まあ、投資した分。
25:35 まあ、どれだけ利益につながったかというものを示す指標です。一方で、 tcoですね、こちら総所有コストというふうにされておりますね。じゃあ、
25:47 内訳どうなっているかなんですが、これはキャペックスとオペックス、 そしてまあ、隠れコストありますが、キャペックス、初期費用ですね。
25:59 そしてオペックス運用費用です。
26:03 これらの合算した数値ということで、ティーシーを計算をしていくことになります。 で、まあ運用費用、これなんか、シグママークついていますけれども、これ
26:13 まあ、言ってみればですね、まあ運用だけじゃなくて、保守とか廃棄、まあ、 こういったライフサイクル全体の費用を、まあできるだけ計算するということになるので、
26:22 まあ廃棄については、これ、まだこれからの部分もあるので、 まあ必ずしもすべてが見えるわけではないということになるので、まあ。予。測。
26:30 を立てるということも必要になります
26:32 なんでライフサイクル全体ですよということで、 ここにまあシグママーク合算した数値ですということをここで示しております。で、
26:41 まあそう、こういった指標を数字ですね、使うことで、 本当に意向がいいんですか、これやっぱり維持するべきなんですかという、
26:49 まあ議論ができるようになるということですね。
27:00 ではですね、次にオンプレとクラウド。まあ、この主要なコストに関する考え方、 間違いが少しありますんで、まあ、これも見ていきたいなと思います。
27:12 オンプレの場合はですね、まあ基本的に初期投資がああ、メインですで、 管理や維持の負担も大きいです。するとですね、まあ、
27:22 こういった形で運用していると、まあ、どうしてもあの投資した分。
27:28 まあ、結構大きな投資があったので、まあすぐに捨てて次に行くという考え方、 どうしても取れないんですね。せっかく投資したんだから、
27:37 これちゃんと使わないとダメでしょうというふうに考え方にどうしてもなってしまうと、 これがまあ、制約ですね。そして、オンプレイの課題とも関連しています。一方で、
27:47 クラウドはですね、こちら。反対に運用の費用。
27:52 これが中心になっています。オペックス運用の費用が中心ですねで、 多くが従量課金の体系になっています。で、ポイントはですね、やはり
28:02 最新技術の活用が簡単ですねということですね。なのでまあ技術を活用となので、 まあ、こういう性質踏まえると、まあ技術を活用するんだということを先に考えて、
28:14 インフラはそれを活用できるように、まあ調整する、準備するという考え方ができます。
28:21 なので、機械ありきで進めるオンプレっていうのと、 まずはまあ技術であったりアプリあったり、
28:29 あるいは実現すべきことありきで進めるのがクラウドであるということですね。まあ、 こういったまず技術やアプリケーションありきで進められる、
28:42 あるいはまあ一方はまずインプラありきで進め。 こういった点がまあ隠れたまあコストとか価値とか、
28:50 まあいろんな違いを生み出す要素になっています。
28:58 では次にですね、移行によるコスト構造の変化、それからコストの最適化について、 これも見ていきましょう。え、まあ、ここにある点を元にですね、まあ、
29:08 移行によりコストを抑えられるんですかということを検討していくことになります。 まずですね、コスト構造どう変わりますか？という点について、
29:18 整理をしておきましょう。キャペックスからオペックスこれはまあ、 初期投資から運用費用へですね。
29:26 初期投資、できるだけ低くしましょうということ、そして、変動費化。まあ、 これはリソースの調整ができるようになるということですね。まあ、結果として、まあ、
29:36 ビジネス的判断でですね、何かここはもうどんどん投資するべきだな、 あるいはここはちょっと撤退した方がいいかなとか、そういった、ああ、投資判断、
29:46 そしてそれを実際のアクションまで実際に行いやすいということも言えるかなと思います。
29:53 そして既存ライセンスの再活用。まあこれはですね、えっと、 オンプレ用に購入したライセンス、まあ引き続き使えますね、ということですね。で、
30:04 運用保守費用の削減。まあ、これはまあ特にあの物理的側面ですね。 物理的なデバイス機器の管理からは解放されるだろうということです。
30:21 続いてコストの最適化について見ておきましょう。 まあ継続的な最適化まあそうですね。これはクラウドサービスとかではですね、
30:29 まあだいたいコスト構造を説明するダッシュボードみたいなもの、あるいはまあ、 ここはちょっとコスト出すぎですね、最適化できますよみたいな、その提案機能、
30:39 あったりするんですね。要するに、こういったものを使うと、 継続的なコスト最適化しやすいということになります。そして予約インスタンスや節約。
30:48 プラン。
30:49 これはですね、えっと、一定の量をまあ一定期間以上使用しますということが、 もうあらかじめわかっている場合は、割引を受けられるというケースは結構多いんですね。
31:00 なので、たくさん使うと、それだとお金かかるなというふうには、 まあそれはもちろんそうなんですけれども、ただお金かかる分、
31:08 ただそれでも割引が効かせられるという余地があるんですね。そこはまあ、少し。 量が増えた、増えただけもうずっと。
31:17 比例して費用が増えるというわけでは必ずしもないということになります。そして このスポットバーチャルマシンスポット仮想マシンというのはこれちょっともしかしたら少しわかりにくいかもしれないんですが、これはですね、まあ少し変わったケースかもしれません。これはスポットVMこれはAzureで余剰となったリソースもうこれを使う仕組みなんですね。なのでまあ、一時的に処理停止しても大丈夫です。
31:49 Azure側がこれちょっと使いたいからといって、Azureに使わせてあげると、 まあ、そういった場合だったら割引が効くということですね。なので、まあ、
31:58 土壌単体リソースを使うので、Azure側がまあ、他で ちょっと今需要が高まっているタイミングなんです。そちらに
32:04 リソースを回させてくれませんかねというふうになった時に、あ、大丈夫です。 大丈夫です私たち、特に急いではないので、
32:11 Azure側でもうどうぞ使ってくださいと。まあ、そういうふうに言えるような状況で。 あったらまあそういう処理をするだけのサーバー仮想マシンであったら
32:19 その場合はまあプランとして、まあ安くしてもらえるということになります。まあ、 コストの最適化要因、結構たくさんあるっていうことですね。なので、まあ、
32:30 コスト構造をどう変わるか、 そして追加的にどういう割引が受けられるかという点を整理した上で、
32:37 コストどういうふうに変わっていきますか？というのを見ていくと良いかなと思います。 そしてコストを考える上で。
32:46 まあ割引についてもですね、まあ理解をしておくと良いかなと思います。 Azureハイブリッド特典まあ既存のライセンスで
32:54 コストを最適化しましょうということです。これはですね、 まあオンプレのライセンスですね。まあ、オンプレ運用している以上は
33:02 何らかのライセンスあるはずなんですけれども、 まあこれをクラウドへ引き継ぐことができるということになります。なんでまあ、
33:10 これは移行検討士がですね、まあ、積極的に活用を検討するべきと。
33:15 いうことになります。まあWindows Serverであったり、 SQL Serverであったり、まあ、主なものは
33:23 だいたいここでカバーがされております。で、こうした点はですね、まあ、 他のクラウドでなく、まあ、Azure利用をすることで、
33:31 まあコスト抑制につなげられるというポイントになってくるかなと思いますので、 これはぜひ覚えておくと良いのではと思います。
33:46 ではここでまとめに入ります。本節のまとめ、移行時に注目すべきアールオーアイ、 それからtco考え方を見てきました。まあ移行時の経済性評価ですね。
33:57 まあオンプレからクラウドを移行するにあたってはもう両者で比較を行うための数字、 意思を出さなければいけません。こうしたコスト構造変化であったり、
34:07 あるいはまあ得点による割引であったり、 そういったものを含めて経済性の評価できるようにしておくと良いかなと思います。
34:17 では次のパートではですね、まあ、クラウド以降のビジネス化、自信、 あるいは成功事例といったもの、これを見ていきたいなと思います。
34:29 クラウドにすると何が得なんだとまあ言っておりますけれども、これ、まあ、 給食の問いですよね。まあ、あのコストについては、まあ前説で、
34:41 前説で確認しましたので、ここではコスト以外の比較可能な指標について。
34:48 まずはいくつか見ておきたいなと思います。コストの削減については、これは。 先ほど見てまいりました。次の俊敏性向上、これはああ、
35:01 何だろうかというものですが、これはですね、まあ、プロダクトのまあ市場投入までの時間、 これを短縮するんだということを指標としています。まあ、
35:14 例えば市場投入の時間50%短縮しますよとか。
35:18 まあ、こういった目標を掲げるっていうことですね。まあ、開発を一部効率化したりとか、 あるいはプロダクション環境を作るっていう時に、
35:27 スムーズに調達することができるということになります。で、パフォーマンス改善。 これは応答時間の改善であったり、まああるいは処理時間の短縮とか。まあ、
35:38 こういったものを指標として掲げるということですね。
35:44 まあ、これはインフラの制約なくなってきますんで、 まあ必要に応じてスケールアウトするとか、まあすなわち処理するサーバーの数、
35:54 今処理忙しいからサーバーの数増やしますとか、 そういったあの選択肢が取れるようになるんですね。なので、
36:02 結果的にパフォーマンスを改善する余地がまあをかなり可能性がかなり高いということになります。そして可用性の向上ですね。
36:11 これはまあ、あのクラウド側がサービスレベル、アグリーメント、エスエルエー、 そしてまあ、サービス、これくらいの、
36:20 稼働してますよというのを指標公開しております。基本的にはですね。。 私たちが作るアプリケーションのロジックとかインフラの設計が正しいという場合は、
36:32 もう基本的にも非常に高い可用性を達成することができます。そして運用効率化ですね。
36:38 はデプロイ時間の短縮であったり、 あるいは自動化される作業の比率が高まったということで、
36:45 運用は効率化していますねということが言えるようになるということになります。 まあ特にですね、まあインフラのデプロイとか、まあ構成の変更とか、
36:56 まあ事前に提示したものがあったら、もうそれを適用する。 ただ適用するだけで済みますんで、非常に素早く行えるということになります。
37:05 そしてセキュリティ強化。
37:07 これはまあ、インシデントの数の削減とかですね。まあ特に物理機器の脆弱性、 パッションの手間が省けるということがありますんで、まあ多くの場合、
37:16 セキュリティを向上させやすいということになります。まあ、 これはセキュリティの話題ではあるんですけれども、だいたいですね、
37:24 あの企業のセキュリティインセント。まあ、ネットワークの侵入とかですね。 そういったインシデント、だいたいはあのブヒビヒゲの機器脆弱な。
37:34 タッチの当てられてないVPN機器だというのがよく言われております。で、 これも物理機器ですね。
37:40 ちゃんとメンテナンスしてないからそうなるというのであるんですけれども、 そういったも基本的に自分たちでファームウェアだなんだと管理する必要ないので、
37:51 まあ結果的にはセキュリティ、強化されてますねということになります。 そして従業員満足度。これは
37:58 結構あの判断が少し難しいところではあるんですけれども。
38:03 まあ、例えばリモートワーク環境、整備しやすいですね。ということで、 まあそういったものを使って、利便性向上しますとまあ管理に当たっても
38:15 働き方改革っていう文脈ですかね、そういったもので、 重量に満足度向上というものにも貢献する可能性というものがあります。え、まあ、
38:25 こうした点を踏まえまして、まあ、クラウド以降のシナリオについて、 これもいくつかVKがあるかなということで、ここでまあ、ごく簡単に。
38:37 紹介をしておきたいなと思います。これはまあ六つ挙げていますけれども、 まあ一つ一つ見ておきましょうか。シンプルなイヤースへの移行まあ、これはまあ、
38:47 シンプルなサーバー群の移行ですね。オンプレのサーバーを仮想マシンに移行します。 そしてインフラ管理負荷軽減します。これはもうあのめちゃくちゃシンプルな例ですね。
38:59 もう一番よくある例じゃないかなと思います。
39:04 そしてバーチャルデスクトップですね。この環境をクラウドで整理するということ。 これまあ、利便性向上にもなりますし、あるいはまあ、セキュリティを。まあ、
39:15 利便性とセキュリティですね。これを両立できるという選択肢としても有用です。 まあ特にリモートワーク導入の波が来た時は、これは特に注目されました。まあ、
39:25 あのコロナとかですよね、 あのコロナの時はもうリモートワークしましょうねということになったんですけれども、
39:32 ただその場合。
39:33 割と多くの環境が。まあ多くの会社様が、まあいや、 うちはちょっとまだリモートワークの準備ないなということで、
39:40 まあかなり困っていたんですけれども、それでまあVPNとか、まあ経由したり、まあ、 一時的にそういった機器を使って、
39:47 リモートできるようにしたりしたんですけども、それを狙って、まあ、 あのセキュリティイニシャが起きたりとか、
39:53 ネットワークトラフィック足りなくて業務続行できなかったりとか、 そういういろんな問題が当時発生しました、こう。いったものももう最初から
40:03 コンプレで用意するんじゃなくて、もうクラウドで用意しておくと、まあ、 そういった問題も発生せずにスムーズにリモートワーク導入できますね、
40:11 ということが言えます。そして、VMウェアソリューションですね。まあ、 VMウェアの仮想環境をクラウドに移行する、これもですね。まあ、関連するまあ、
40:20 外部要因変化の件、先ほどご紹介しましたけれども、 そういったものを考えると非常に代表的なケースになってきています。
40:31 まあ、それ以外にも、いくつか事例が、 まあシナリオの例というものがございます。これは主にですね、まあ、
40:38 クラウドが持つリソースの調達のしやすさであるとか、あるいはまあ可用性であるとか、 こういったものを注目したユースケースですね。例えば基幹システムであったら、
40:49 これはもうあの絶対に止めちゃいけないシステムですよね。
40:53 で、それをいかにして安定的に稼働させるかっていうことを考えると、 まあオンプレイよりも、
40:58 かえってまあAzureとかクラウドの方がいいんじゃないかなということもありえます。 そしてHPC、これはもう計算リソースですね。これ、
41:06 あの一時的にしか使わない計算リソースじゃあ、 巨大なサーバー室オンプレイに作るかって言って作れるかっていうと、
41:13 よくできるかっていうと難しいんですよね。もう巨大な。ああ、 演算環境を用意するってなると、なかなか勇気が。いるんですがまあ、
41:20 クラウドだとやりやすいということになります
41:24 あとまあ、データ分析期間、これもそうですねといろんなところとね、データ集めてきて、 それの上で分析するとか、こういった場合、クラウドの方がやりやすいよということですね。
41:38 まあ、いろんなパターンがあります。ではですね、次からは 実際の導入事例ですね。これを三つ見ていこうかなと思います。
41:54 事例の一つ目はですね、横川電機様の事例ですね。 まあ非常に大規模にリフトアンドシフトを遂げたということで、
42:03 紹介をしております。 こちらウェブサイトの方でも記事が用意されておりますので、
42:11 こちらは適宜参照していただくと面白いかなと思います。で、 この横川電機様の事例なんですけれども、こちら。まあ770台という。
42:21 まあ300台と。
42:23 まあ、非常に大きな数ですね、オンプレ。仮想のオンプレの、まあ仮想サーバー環境を 大規模にAzureに移行した。そしてさらにまあ、700台ですね、
42:33 これも結構な数なんですけれども、 バーチャルデスクトップへの運用に移行したということが記載されております。
42:42 そして加えてですね、まあ、基幹システムの移行についても、 取り組みを進めておるということでした。
42:51 まあ、使われている、使われている製品サービスであるとか、こちらまとめております。 まあこれはですね、このケースですとまあオンプレで、まあそもそも
43:03 各種のMicrosoft製品運用していたということなんですねえ。それで 既存環境との親和性が高いなと。加えて、えっと、
43:12 ここで紹介はされているかなと思いますが、こちら足りないか。まあ、 あと拡張セキュリティ更新プログラムですね。
43:21 なんでまあ、ちょっと セキュリティ構成に少しだけ延長できますっていうプログラム、
43:27 それから認定パートナーによるサポート体制、これらも考慮する？ 考慮されたというふうに記事では言及がされております。なので、まあ、
43:37 ここではまあ、 仮想サーバー環境機能として十分だからっていうことももちろんあげられるんですけれども、
43:44 そういったサポート体制であるとか。
43:46 そういったことも考慮されて、 Azureを選定したというユースケースになっております。ただまあ、
43:56 一番大きいのは、 まあ既存環境をクラウドでもフル活用できるんですというのがちゃんとお客様に伝わったという例ですね。では次の方に行きましょう。事例の2つ目。こちら。富士フイルムソフトウェア様ですね。こちら。
44:18 まあ、フォトイメージング事業ですので、 まあ非常に中核事業にあたるものですけれども、このフォトイメージング事業、
44:26 こちら実はですね、先行して仮想マシン、 Azureに移行していたんですね。ただ、その際には全面的な移行ではなくて、
44:35 ナスネットワークアタッチストレージまあストレージはですね、 オンプレでやっぱり維持した方がいいねということになったみたいなんですね。まあ、
44:44 こういった都合から、まあ。
44:46 当初はハイブリッド構成をとっていたということになります。で、こちら。 こちらの記事であるので、読んでいただくと面白いんですけれども、
44:56 まずあの最初の段階ではですね、この2021年の段階では、 一応あの導入フル以降検討されていたみたいなんですね。
45:05 すべてをまあクラウドに持っていこうということが検討されていたと。え、その段階では。 え、ストレージについても、Azure files premium。
45:16 これ導入するといいんじゃないかなということで、 検討がどうもされていたみたいなんですね。ただ、それでも計算していくと、
45:23 オンプレ上の、まあスケールアウトナスというソリューションあるんですが、 そちらの方がまあコスト面では優位だったというふうに書かれております。まあ、その後、
45:35 filesの移行するということになってはいるんですけれども、これがですね、 Azure network files、
45:42 当時はまだ日本リージョンでは展開されていなかった。
45:46 そうなんですね。なので、まあ、 どうしても見送りになってしまったという経緯があります。あ、ちなみにですね、
45:53 えっと、ネットワークファイルズ、まあ、さらっと流してしまいました。これ、 ネットワーク社ですねのこの高性能なファイルストレージ技術を使用したストレージサービスです。で、ちょっと戻りまして、その後ですね、オンプレが利用する。まあ共用のデータセンター稼働終了という流れがあったみたいですね。その際に。
46:15 やっぱりじゃあクラウド移行しようかなということで、 クラウド移行の検討を本格化しました。そしてまあ、最終的に、
46:24 Azure network files導入するといいなということで採用がされました。 で、このソリューション、Azure net APP files、
46:34 これ何が注目されたかなんですけれども、これはですね、こちら記載をしておりますが、 動的なパフォーマンスの調整、これは可能であった。
46:43 結果、それでコストの最適化に成功したということなんですね。まあ、 これまでスケールアウトナスの方が、まあ、うまくうん、
46:50 コストとしてはまあ安いなということだったんですが、こういった、 新しく日本で展開されるようになったソリューションを使うことで、
46:58 コストやっぱりこちらの方が最適化できるな、うまくいくなということで、 クラウド移行するにあたって、
47:04 ふさわしいというふうに持っていくことができたというケースですね。
47:09 まあ、動的なパフォーマンス調整にコストの最適化、これが果たされることで、 まあ実際に課題とされていたものも、解決できたということになります。で、
47:22 この例ではですね、まあ、コストの最適化に成功したという内容以外にも、実はですね、 あの重要なポイントがあるんじゃないかなと考えております。
47:37 これ少し、どういうものか想像できるでしょうか。まあ、 少し話はしたんですけれども、重要なポイントがございます。何かというと、まあ、
47:48 クラウドの全面移行が一度は見送りになったという流れがあるんですね。ただ、 転機が訪れました。そして改めてクラウド移行を検討したという時に、
47:59 要件を満たす製品がまあタイミングよくあることを伝えられたんですね。
48:04 そうすることで、クラウドの移行が成功したということになります。ですので、 一度クラウド移行、やっぱり見送りだよということになった場合でもですね、
48:14 きっかけがあれば、 移行を促すというチャンスがあるということをまさに証明した事例になるんですね。
48:21 ですので、まあ、新しい製品であるとか、新しいサービス、 あるいは新しく日本にサービスが展開されるという動き、
48:29 これは非常にあの重要なものだと思いますので、できる限り。
48:34 情報を収集していただくと良いんじゃないかなと思います。そして過去にですね、 お客様の提案で、今回オンプレの方がまあコストメリットうん、
48:42 あるなというふうになって見送りになってしまったという場合でも、 新たに利用できるようになったものを使えば、
48:48 やっぱりコスト最適化できるんじゃないですかということで、 最低案に持ち込むということも可能になるということなんですね。
48:56 この実際に行った例がこちらであるということです。非常にまあ、面白。い。え、 え事例であると思うのでぜひ
49:02 こちらネット上の記事についても読んでいただくと良いのかなと思います。では、 最後3つ目の事例ですね、こちら今治造船様ですね。
49:16 こちらの事例になっております。これはですね、 オンプレイにあった基幹システムですね、これをアジルの方に移行したということです。
49:29 こちらのきっかけになったのは、ハードウェアの保守期限切れですね。
49:36 星の期限が切れそうだからということで移行を計画しました。 そしてAzureへリフトすることでコストの削減にも成功しました。で、
49:46 オンプレイではですね、まあ問題になってくるのが、あの導入時点でスペック不足だと、 これ非常に問題が大きくなってしまうんですね。特にこう注目したいのがこれ、
49:59 基幹システムなんですよ。基幹システムは絶対に止めてはいけないシステムですね。
50:05 絶対に止めてはいけないがゆえに、あらゆるリスクを排除するというのが、 もうプロジェクトではもう大前提になってきます。なので、どうしてもですね。
50:15 じゃあこれをオンプレで基幹システム運用しようかということになると止めちゃいけないので、スペック不足なんていうことが起きては絶対にいけないんですね。なので、結果的に必ずオンプレで基幹システムやりますよってなったら、スペック面でちょっといいものを注文せざるを得ないんですね。機械とか。
50:35 結核、もうこれはもうほぼ100%、最初、オーバースペック気味で、上達します。 それがまあ少し、まあもったいないなということがあるんですね。
50:45 もちろん問題がないんだったら、それはそれで一番幸せなことなんですけれども、 ただやっぱり問題がなくてよかったけど、
50:53 ちょっともったいなかったかなというふうになってしまうんですね、お客様としてはで、 クラウドではそういったことが、なかなかああ、なくなりますと、まあ必要十分。
51:05 で、ちょっと足りなくなりそうだなということは、予測されるんだったら、 まあ少し上にグレードを上げるということができるということですね。ですね。まあ、
51:15 こういったオーバースペック気味になっちゃいますよというケースこれをまあ、 うまくクラウド以降で課題を解決したという事例になっております。
51:26 それ以外にもですね、こちらもぜひ、 記事を読んでいただければ良いんじゃないかなと思うんですけれども、まあいくつか、
51:34 非常にAzure良かったよという点が紹介されております。例えば、 Azure migrateですね、Azure migrateという、
51:42 まあ移行関連のツールあるんですけれども、これからですね、 適切なサイジングですね、これを計画しに進めることができたということですね。まあ、
51:50 こういうこういう機関、システム計画しています。
51:54 で、クラウドではどれくらいのスペックで用意すればいいんだろうっていうのが、 最初はなかなか選ぶの難しいかもしれないんですけれども、まあ、
52:02 こういったツールとかもうまく使うことでサイジング、まあ、 どういったスペック用意しましょうかねということも。計画時ね、
52:09 うまく進めやすかったということが言われております。そして、あとはですね、 ファストトラックフォーAzureまあ、こういったものを使って技術支援を得られたので、
52:19 テス。ト。時に発生。した問題もこれもスムーズに
52:22 解決できましたということも言われております。あるいはですね、まあこういった、 移行時に発生する諸問題も解決できるという体制も有効であったということですね。まあ、
52:33 こういったスペック面での注目ももちろん重要なんですが、やはりお客様結構ですね。 あの基幹システムとか、絶対に止めちゃいけないシステムのプロジェクト、
52:44 これも慎重になるんです。みんな慎重になるということはもうとにかく まあAzureの。
52:50 こういったサポート面もそうなんですけど、不安になっちゃうんですかね。なので、 サポート体制どれだけ充実できてますか？サポートどれだけしてくれるんですか？
53:00 っていうこともコストと合わせて、やっぱり不満失礼、不安に思ってるんですね。 その不安も解消できるようなプランがあるんですよね。っていうことが説明できると、
53:10 やっぱり安心して移行できると思います。本講座ではですね、どうしてもあのああ。
53:16 サービス面、こういうことが対応します、コスト、 こういうふうに削減できますという紹介が、まあ中心にはなるんですけれども、一方でまあ、
53:24 お客様の不安を解消しますと懸念を解消しますという観点では、 それに加えてまあサポート体制も充実してますねという観点を持つと、
53:32 非常に有効であるということが言えるんじゃないかなと思います。 こちらもぜひ記事を読んでいただければと思います。
53:46 それではですね、本節のまとめに入ります。まあ、 クラウド移行時の効果測定や成功事例こちらを学んでまいりました。まあ、
53:55 いくつか成功事例紹介してきましたね。まあ、効果測定の基準であるとか、 こういった成功事例ですね。これを参考にして、
54:03 まあ提案を行っていくと良いんじゃないかなと思います。そしてですね、少し、 これまでも触れてまいりましたけれども、成功事例ではですね。
54:13 まあ使用された製品、まあどういう機能を持ってますかとか、 そういったその製品どこで使いますかっていうユースケースだけではなくて、
54:22 まあ何が決め手となってAzureを選んだんですか。で、 どういうタイミングで意向を審議検討したんですか、
54:28 あるいは意向を再建どうしたんですかという点にも注目してみるといいんじゃないかなと思います。あ、ですみません、少し戻ってしまいますが、え、え、こちら事例。三つ紹介しておりますけれども、これあのいずれも。ウ。ェ。ブ上に記事がありますので
54:44 他にも記事たくさんございます。なので、過去成功した事例では、 どういうところが検討されたんですか？製品としては何を検討したんですか？
54:52 どういうタイミングだったんですか。 こういったものを見ていただくと非常に勉強になるかなと思いますので、
54:59 こちら全部はここでは紹介してはいないんですけれども、 ぜひご自身でも検索としていただいて、見ていただくと、
55:06 まあとても参考になるんじゃないかなと思います。
55:14 それでは。本章のまとめです。本章ではこちら。 確認してまいりました。オンプレ環境の典型的な課題とリスクまあ、
55:24 オンプレが抱える典型的な課題とリスク説明できるようになったでしょうか。 どういったものがあったでしょうか。五つのポイントですね。
55:35 そして移行時に注目すべきアールオーアイ、それからティーシーを考え方。 これも見てきました。まあキャペックスとかオペックスとか、あと隠れコストありましたね。
55:46 そしてクラウド移行によるビジネス価値、それから成功事例。これも三つ。 見てまいりました。クラウド移行がもたらすコスト、あるいはまあ削減以外
55:56 コスト削減以外のまあビジネス価値成功パターンある程度見てきましたが、 整理できたでしょうか。
56:05 まあ細かい点はですね、あの様々にあると思います。結構ですね、いろいろ見てきましたが、 まあ少しあのまとめる際は個別の要素をどうしても整理し出すと、
56:15 たくさん情報が出てきますんで、まあ、まずはですね、ちょっと戻りますけども、 この成功事例のところ、
56:22 これからまあさかのぼって考えて整理していくといいんじゃないかなと思います。で、 そして繰り返しますが。
56:31 記事はもうたくさん。ウェブ上にございますので、ぜひ見てみてください。 そしてそこから、まあどういった情報がああ重要かというのを、まあ抽出していく、
56:44 練習するとかしておくと、結構提案の際にも役に立つんじゃないかなと思います。 それでは第一章は以上となりますはい。それでは時間となりましたので、
56:57 再開させていただきたいと思います。
57:02 それでは続いて第二章ですね。Azureでシステムを動かすため、 Azureインフラの基本的なコンセプト紹介をしていきます。
57:14 オンプレとAzureをどう代用させるか、 まあ理解をするための基礎部分となってまいります。で、本章の内容ですが、あ、
57:24 まあこちらにあります通り、まず、Azureの要素技術ですね。
57:31 そしてクラウド移行時のまあ運用管理とセキュリティの基本に関すること、 そしてまあ、VMウェア環境の移行に関するトピック、こちらを取り扱ってまいりますで、
57:42 まあ、基本的にはですねこの図で示すステップで理解を深めていきましょう。 移行時にはですね、まあ、オンプレイのシステムのうち、まあどういった点、
57:53 確認するべきか。例えばマシンのスペックどんなもんですかとか。
57:59 ネットワーク構成どうなってますかとか、まあ、そういったものですね。まあ、 そしてクラウド移行した後、運用管理面で得られる一般的なメリットなんですか？
58:10 ということ。そして、まあ、特に仮想環境運用する場合ですね。まあ、 どういった移行パターンがありますかということ。これらを整理していきましょう。
58:22 それでは、要素技術を個別に見ていきます。
58:29 お、なんかちょっと面白いが出てきましたね。。 唐突に登場するクラウドマンクラウドマンが贈り物をくれたようです。
58:36 その贈り物の中にはですね、まあIDであったり、ストレージであったり、 あるいはネットワークに関するものであったりと、こういったものが含まれております。
58:46 まあ、こうした個別の要素をですねえ、簡単に見ていきましょう。
58:53 え、まずはですねえ、 次以降のページで取り上げていく内容をチェックしていきたいと思います。はじめにえ、
59:00 IDとリソース管理に関することまあ、仮想マシンであるとか、まあシステムの構成要素、 これはリソースという形でサービスで扱われます。その管理に関することですね。まあ、
59:10 どういう形でまとめていくか、そして次はシステム構成ですね。まあ、リソースの作成後、 まあそれは関連付けるための、まあ基本的な構成、まあ幅のスポークとか、
59:20 そういった構成に関すること。
59:22 それから基本的にはWebアプリを作る場合の構成、 これらを例にして解説をしていきます。そして、
59:30 Azureの仮想マシンバーチャルマシンについて、まあ、仮想マシンの種類であるとか、 仮想マシンサービスの種類、これをまあ概略的に紹介をしていこうと思います。
59:41 そして、ストレージいいですね、これ。 まあサービスの種別こちらも簡単にご紹介をしてまいります。
59:50 そしてネットワークと接続ですね。まあ、これは オンプレと仮想マシンAzureの仮想マシン接続方法について、こちらも
60:00 概略的に見ていこうと思います。では、 IDとリソース管理の観点これを見ていきましょう。この、
60:08 まずIDについてなんですが、 これはあのMicrosoftエントラIDというものがあるんですけれども、
60:15 まあこちらの詳細はですね、あの午後の。
60:19 セキュリティに関する講座で取り上げていきます。ここではまあ明るく ここでさらっと書いているだけとさせていただいております。
60:29 リソースの構成についてはですね、中央の図で表現されるこの階層構造、 まず理解しておくと良いかと思います。テナントがあって、管理グループがあって、
60:40 サブスクリプションリソースグループまあ、 こういう形で階層構造がああ作られています。
60:48 え、テナントはですね、これは例えばまあ一企業とか、 まあそういうレベルで考えてください。で、管理グループは一旦飛ばしまして、
60:57 サブスクリプションですね、こちらまあ課金と管理の単位ですね。 まあ例えば部門レベルでまあ分けたりとか、あるいは本番環境です、これテスト環境です、
61:07 開発環境ですとか、まあこういった形で環境の別に分けてるとか、 これはあのルールがいくつかあるかなと思いますね。
61:16 で、リソースグループこれはまあ、例えば、まあ、 作成するアプリとかのサービスがあったとして、
61:23 これらの単位でグルーピングして分けておくというものだと言えます。 これはまあでも要求に応じて、まあいろんな分け方があるかなと思います。え、まあ、
61:32 ちょっと戻って管理グループなんですが、これはあのサブスクリプションよりも、まあ、 ある意味では上位のグループですね。まあ、サブスクリプション自体を何らかの形で、
61:43 まあくくりでまとめるといったものに。な。り。ます
61:46 これはまあ、必要に応じてまあ深くしていくこともできますんで、 これは管理上効率がいいやり方っていうものを見つけていただければと思います。
61:55 あとですね、リソースグループ内の各リソースまあタグによってですねまあ、 分類するためのヒントであったり、あるいは各種のメタ情報であったりとか、
62:04 こういったものを付与することが可能です。まあここでまあ、開発環境ですとか 営業部門ですとか、まあ、いろいろ書いてますけれども、まあ、例えば。え？
62:14 えリソース作成者誰ですかとか
62:16 あるいはまあコストセンター何番ですとか、 まあそういった情報を付与するというケースが結構あるかなと思います。あとまあ、
62:23 リソースの管理ですね。作成とか削除とか、そういった操作をする場合は、これは いくつか選択肢があります。まあ、だいたいあのAzureのポータルで、最初はまあ、
62:34 スタートはそれでいいかなと思いますが、 それ以外にもコマンドラインのツールを使うとか。
62:40 あとここにアームテンプレートなんていうのがありますけど、これ？いわゆる
62:45 アイエーシーインフラストラクチャーズコードになってきますね。まあ、 こういった形で行動で管理するっていうこともできますね。こう、まあ、
62:55 こういった形でどういう単位でリソースをまとめていくかというのは、 設計においてまあ非常に重要なポイントとなってきます。
63:05 次はシステム構成ですね。 ここではまずハブアンドスポークのネットワークパターンこれをまあ簡単に見ておこうかなと思います。これはですね、まあ、要はハブとなる。まあ共通。の。
63:18 ネットワークみたいなものがあるんですね。 この共通のみんなが通るネットワークこれを介して、システムのaとシステムB、
63:27 あるいはまあシステムaとシステムCみたいな形でつながっていくということになります。 あのつまりはaとBが直接接続しないというようにする。まあ、そういった構成ですね。
63:39 あとまあ、コンプレの方もですね、これもハブに接続しているという形になります。
63:46 なんでまあ、このハブにあたるもの、共通の機能、ネットワークこれがまあ、 常に中心にいるという構成ですね。中心にあるっていうことは、まあ、
63:54 あらゆるものはここを通るということになります。なので、 あらゆるものが通るということは、そこに例えばまあゲートウェイであったりとか、
64:01 あるいはファイアーウォールであったりとか、こういったものを設置することで、 これらをまあ要は門番みたいな形で運用するということができるということですね。
64:12 あとまあ、ここにバスジョンが書かれておりますけど、これは また後で少しだけ触れていきます。まあ、こういったハブアンドスポークという、
64:22 まあ基本的なネットワークの構成がありますんで、 これを覚えておくと良いかなと思います。
64:28 そしてこのまあハブアンドスポークをまあ想定しつつも、ここでは一般的な、 まあ三層ウェブアプリの構成、これをちょっとチェックしていこうかなと思います。
64:41 三層ウェブアプリ三層ってなんだ？という話なんですが、これは三層っていうのは。 一つはユーザーに見せるウェブサーバー、ウェブアプリですね。の部分と、
64:52 そのアプリのコアロジック部分ですね。アプリのコアロジック部分、 そしてデータを保管する部分、この三つですね。
65:00 ウェブサーバーアプリケーションのサーバーデータベースという感じですね。で、 この例ではまあ、こうした機能の単位でサブネットを分割しています。
65:11 ウェブサブネットでアプリケーションのサブネットでデータベースのサブネットこのサブネットはですね。まあ、仮想ネットワークまあ、実はこの白いところ、仮想ネットワークなんですが、この仮想ネットワークの内部、さらにまあセグメント分けした、まあ細分化されたまあネットワークといったようなイメージで捉えると良いかなと思います。そしてですね、サブネットの中にはあのネットワークセキュリティグループっていうものも、これも配置がされて。お。ります
65:39 これはまあ言ってみればサブネットに入ってきて、いい通信これですとか、 まあ必要な通信だけは出入り。出入りできるようにするための。まあルールですね、
65:49 まあ、こういった構成がとられております。で、デイによって、まあオンプレからもあ、 接続できるしで、これがあのウェブサーバー公開しているウェブサーバーであれば、
66:00 インターネット経由で通信が入ってくるということもあります。ここでもですね、 あのバッションが出てきてますね、バッション。
66:08 早く紹介してくるみたいな感じになってきておりますけれども、このバス帳のなどから、 まあ他のサブネットマシンにアクセスして、メンテナンスの操作とか、
66:18 こういったところからああ、できるようになってます。 この管理サブネットというところから、他のウェブサブネットとか、
66:25 アプリケーションのサブネットとかにある仮想マション、 メンテナンスするということができるように構成がされています。で、仮想マシンの、
66:34 まあ種別についてはですね。
66:37 まあ、非常にたくさんあります。かなりたくさんあるんですが、 まあ大体の分類、どういったものがどういった形で分類をしているかというものを、
66:46 まず理解しておくと良いんじゃないかなと思います。ちょっとだけ。 見ていきましょう。まずこれ。低コストというものがありますね、これ、まあ、
66:56 言ってみれば、コストが低いということは本番で運用するものじゃないので、 まあ開発時とかに使うようなものかなというところですね、開発のサー。バ。ー
67:05 で、汎用性。まあこれはまあ、あのバランスがいいというものですね。なので、 まあとりあえず、まあ、迷ったら一旦これで選ぶみたいな扱いになるかなと思います。
67:16 そしてこれ以降はメモリー最適化、コンピューティング最適化、ストレージ最適化と、 まあ続いていますね、これ以降はですね、
67:24 まあ計算書の特性に合わせて選んでいくということになります。 メモリたくさん食いますというような書類がだったらメモリ最適化ですし。
67:33 で、計算処理すごくずっとずっと回すような、サービスですって言うんだったら、 コンピューティング最適化ですし、で、データたくさん扱いますよという場合、
67:44 ストレージ最適化ですし、こういった形で どれがふさわしいのかっていうものを処理の特性に応じて選んでいくということになります。
67:52 あとまあ、機械学習とかであれば、 まあご存知のジーピーユーケージーピーユーですね。
67:58 こういったインスタンスを使うということになります。
68:02 まあ、用途に応じて適切なものを選ぶということになります。で、 仮想マシンのうちですね。まあ、ちょっと特殊なものもいくつかございます。で、
68:14 これもいくつか見ておきましょう。まずAzureのブースト、 Azureブーストですね。まあ、少し難しいんですが、まあ、
68:25 仮想マシンのサーバーですね、これは本来は。まあ、例えば計算上にねサービス。
68:32 続行するための計算処理を行うとかいうことがあるんですけれども、 仮想マシンであるということは、まあ仮想化プロセスと呼ばれるものですね。これが、あ、
68:42 どうしても実行しておく必要があるということで、 ここもある程度リソースを送っておくということになります。で、
68:49 このAzureブーストを使えるものであれば、この、 まあどうしても必然的に食っているリソースというものを、まあ、
68:55 専用のソフトウェアとハードウェアにオフロードする。まあ、そちらにあの負。 担をもう負担してもらうと
69:02 いうことで、まあ、負荷を請け負ってもらうことで、 まあ本来の書に集中できるようにするというようなアイデアですね。
69:10 Azureブーストというものも場合によっては使えるということになります。 そしてAzureコンフィデンシャルコンピューティング。まあ、秘密計算、
69:21 秘密計算ですね。まあ、あの処理中のデータを保護する技術になっています。
69:26 これはですね、あの午後のセキュリティの章で取り上げていきますので、ここでは まあ軽く紹介しておきましょう。まあ、メモリーのデータ暗号化、まあ、
69:37 これがキーワードになるというところですね。詳細については、 あの午後の章でご紹介をしていきます。で、バーチャルマシン、
69:45 スケールセット仮想マシンスケールセットこれはですね、 まあその名前からもある程度伺えるかなと思うんですけれども、仮想マシンをまあ、
69:54 ドイツ構成で多数デプロイすると。
69:56 そしてまあ、スケーリングに対応するというためのサービスですね、こういった、 いろんなルールに基づいて、インスタンスを自動的に増減させる、
70:05 トートスケールさせるというものに対応するためのものとなっております。まあ、 これはですね、まあ、そうですね、まあ例えて言うと、まあ、スーパーとか、
70:14 まあドラッグストアとかですね、もうレジ待ちの列ができていますと、レジ待ちの列、 お客さんサーバーかんといかん。
70:21 この時ですねどうしても待っていると、どんどんどんどんお客さん後ろに、 後に後続いていってしまう。さばききれないなとなるので、この場合、
70:29 担当者を増やして、 まあ対応レジ追加して別待ちを解消するということをされているんじゃないかなと思いますが、まあ考え方は同じですね。そういう形で、コンピューターの世界でも、まあ、オートスケーリングという形で、いわば対応レジを追加するみたいな形でたくさんある処理というものをさばいていく。と。いうことができますそれをサポートすることができるということですね、
70:52 で、Azure computer freeと、これもまあ、 ある程度同様の考え方ではあるんですけれども、仮想マシンスケールセットと違って、
71:04 まあ異なるVMですね。これを組み合わせることができるという点が違い違いがあります。 あとまあ、最大1万台とありますけれども、
71:13 まあ非常に大規模にデプロイできるという点でも違いがあります。
71:21 こういった形で、まあ特殊なものもいくつか用意されていますので、 まあ要件に応じてこういったものがあるんだなと知っておくとより細かく要件を定義できるんじゃないかなと思います。そしてストレージについてですね。まあ、データ保管する場所なんですが、これは主要なものを三つだけ紹介します。まあ他にもいくつかあるかもしれませんが、まあ主要なものだけ取り上げておきます。
71:48 まずAzureのマネージドディスクですね。 仮想マシンにマウントできるストレージということになっております。まあ、
71:56 処理を行うサーバーとかがですね、まあ参照するデータあるかと思うんですけども、 そういったものを格納しておいて、まあそれを
72:04 サーバー間の共有ディスクみたいな形で、利用できるということになります。そして、 グローブストレージこれはまあ、いわゆるオブジェクトストレージですね。
72:17 まあ、あの大量の画像データとか、 あるいはログデータとかをまあ保管するっていう場合に最適ですね。
72:23 まあ積極的にまあいろいろアクティブに使うということも、まあできなくはないんですが、 まあ、どちらかというとまあ保管をするんだとたくさん保管するんだとか、
72:34 意義が強いものですね。そして。Azure filesこれはまあ、 あのファイル共有のサービスですね。まあ、
72:42 あの一般的なあのファイル共有サーバーみたいなもの。
72:45 オンプレでももしかしたら運用されているかもしれませんが、 まあそれと同じ感覚で使えるサービスなんだなということで理解していただければ良いかと思います。まあ下にもですね。えっと、こういう形で使い、主な使い分けについてはここでご紹介しておりますので、まあそういった使い分けを意識しつつ、まあこういったサービスあるんだなということで理解していただければ良いかと思います。
73:15 ではですね、ネットワークと接続についてこちらも見てまいりましょう。ここではですね、 オンプレット、オンプレットAzureこれをどのように接続するかという観点、
73:30 それからAzure内でまあサブネットを分割しますよという観点。 これを確認しておきましょう。まず、オンプレとAzureの接続ですね。
73:44 これはAzure VPNゲートウェイ、VPNゲートウェイ、 これを使ってVPN接続するという方法と、あとまあ専用線ですね、
73:53 専用線兵器もを使用するエクスプレスルートを使うという方法、 これがまあ主要な方法になっています。まあVPNであれば、まあ、まあ、
74:03 アイピーセックスとか使って暗号化はされているんですけれども。 通信はインターネットを経由します。インターネットを経由します。
74:12 で、エクスプレスルートであれば、まあ、インターネットは経由しません。 オンプレートAzureを専用線で結ぶので、
74:20 まあ言えばオンプレートAzure感兵器化と呼ばれますけれども、 そういった形でつなぐことができます。で、このVPNなんですけれども、
74:29 このVPN使う場合、まあちょっといくつかパターンがあるということで、 これもご紹介をしておきましょう。
74:38 一つがですね。まあポイントツーサイトピーツーエスポイントツーサイトのVPN。 これはですね、
74:45 えっと端末レベル端末とAzureというレベルで接続をするというものですね。 あともう一つが、サイトツーサイトエスツーエス。まあアイピーセックと、
74:56 ここでは書いていますが、サイトツーサイトでのVPN、これはネットワークですね。 コンプレのネットワークとAzureを関連付けるというものですね。
75:06 この2種類があります。
75:10 ポイントツーサイトクライアントとAzureというレベルだと、 まあ端末レベルでどうしても認証を行わざるを得ませんが、まあただしですね。この場合、
75:22 例えばリモート環境からAzureに入るという場合も使用することができるということになります。まあ一方でサイトツーサイトですね。こちらはまあ個別の端末認証、必ずしも必要はなくなります。
75:37 まあ、社内のネットワーク同士、 社内のネットワークとAzureネットワーク同士つなげるので、
75:44 社内ネットワークにいるのであれば、 自ずとまあVPN経由でAzureのリソースにアクセスができるということになります。
75:53 で、エクスプレスルートを使うまあ、専用線使う場合はですね。まあ、 こちらは専用線の特徴がありました。この場合、
76:02 安定した帯域を確保できるというのがあります。
76:07 まあ、広帯域低遅延というふうに、まあ紹介されておりますが、まあこの場合は 接続が安定するので、まあ特にあの遅延がしてほしくない、
76:16 処理がたくさんあるんだという場合は、あると、 こういったものを導入すると良いかなと思います。ただですね、えっと、これ、
76:24 インターネット経由をしないという点で、まあ分類されているという点では、まあ、 セキュアではあるんですけれども。
76:33 設定する場合、デフォルトでは暗号化はどうもされないということのようですので、 まあ要件に応じて、まあ必要に応じて暗号化の設定は別途を行うということは必要です。
76:45 あとはまあサブネットに関する観点。これはまあ、まあ実はまあ、 前のページも少し紹介したんですけれども、一旦サブネット、
76:56 オンプレからの通信を受けるところ用意しておいて、 それからあとはそこからまた別の機能別のサブネットにアクセスをしていくという形になってきます。
77:14 ではですね、本節のまとめです。まあ、 基本的な様子技術をここで取り扱ってきました。まあ、どういったサービスかですね。
77:24 顧客のお客様のオンプレ環境を再現するために使えるかということで、 まあイメージできるようにしておくとよいでしょう。では次に、
77:34 運用とセキュリティ対策ですね。 あちらで変わる運用とセキュリティ対策これを見ていきましょう。
77:44 ではまずイラストを見てみましょうかこれ、ここではですね、 どうもなんか危ない運用をしてしまっていたんですかね。
77:51 あの仮想マシンが攻撃者に乗っ取られたといった様子が描かれております。特にですね、 あの自宅で作業したいんです。っていうことで、あのリモート接続ですね、
78:00 あのAzureにリモート接続ここでお家からあ、 仮想マシンアクセスするんだというような、運用していると、
78:07 あの仮想マシンをインターネットにさらしちゃうとか、そういう重大なインシデ。 ントを起こすことが
78:13 たまにあるんですね。そうすると、こういったケースがどうしても発生してしまいます。 こういったものを防ぐためにできることというものがちゃんとありますんで、
78:25 まあ可能な限りここで見ていきましょうではですね、運用に関して 五つの軸を扱っていきます。安全なリモート接続。これはまあまあ、
78:35 とにかくインターネットにまずはさらさないというのが大事ですね。
78:41 そして高可用性とスケーラビリティ。 まあ障害あるいは災害が発生した時でもシステムが止まらないようにするというための方針です。そして統合管理。これはまあ、あのガバナンスとかセキュリティとか、これに関連するサービスですね。これを見ていきます。そしてデータ保護pcdr
79:02 bcdr、 あのビジネスコンティニティビジネス継続性とディザスターリカバリー災害復旧ですね。
79:09 万一のデータ紛失であるとか、 あるいはシステムダウンが発生した場合に備えておきましょう。
79:17 そしてAIによる運用支援ですね。 まあCopilotインナージョールこれもまあうまく活用すると良いかと思います。
79:26 では一つずつ見ていきましょう。まずは安全なリモート接続こちらあの二つサービスを 紹介しておりますね。まあ。
79:36 主にバッションの方がまあより重要なサービスかなと思います。これはまあ、 いわばマネージドで踏み台サーバーにあたるものを運用できるということですね。
79:47 これはあのこの図で見ていき、見ていきますと、このこの図の右側にある仮想マシン、 これがいわば管理対象の仮想マシン。
79:56 ここに入って何かメンテナンス作業をしたいという状況です。その場合に、 例えば管理者、管理したいという人、開発者。
80:06 が、まずAzureポータルに入って、それからまあ、 Azureバッションで仮想マシンを起動します。そうすると、そこで起動した仮想マシン、
80:17 ここからその管理対象に入っていくということができる。 これがバッションのサービスですね。この場合、Azureポータルを経由して、
80:26 そこそこからもバッションに入って仮想マシンにたどり着くということになるので、 どこにもですね、仮想マシンに。
80:35 さらされているものが。あ、 仮想マシンでインターネットにさらされているものがないということになります。で、
80:43 このあたりはですね、セキュリティのショーでも扱っていきますんで、 これも軽くここで触れております。そしてもう一つ、
80:51 Windows admin center in Azureポータル。まあ、これ、 あの名前が示す通り、これもあのAzureポータル経由で
81:00 使えるという管理系のサービスですね。
81:04 まあメリットはまあほぼほぼパッションと同様かもしれませんが、こちらは まあウィンドウズと名前に関されています。通り、
81:11 ウィンドウズサーバーがメインターゲットになっています。 パッションは必ずしもそうでもないんですけれども、まあこちら、
81:18 まあ幅がちょっと狭いということは言えるかなと思います。まあそれでもまあ、 ウィンドウズサーバー使っていいという場合は非常に簡単に使えるということで、
81:27 でも知っておくと良いかなと思います。
81:34 ではですね、高可用性とスケーラビリティ、まあ、 システムを止めないというための工夫について見ておきましょう。まあ、
81:42 可用性を損なう要因としてですね、まずまあ、大量アクセスの発生、それからまあ、 災害の災害による障害発生といったものが挙げられるかなと思います。まずですね、
81:54 大量アクセス発生した場合どうしますかということにですね、それを考えていきましょう。 まあ、通信が大量にAzureに寄せられてきたと。
82:04 いう状況下で、この場合、まず最初にロードバランサーがそれを受けますと。で、 ロードバランサーでまあ異なる。仮想マシン、異なるアペラビリティ、
82:13 その仮想マシンに処理を振り分けるということを行っていきます。で、まあ、 もしあの振り分け先が足りなくなったら、振り分ける先をまあ増やしていく、
82:21 仮想マシン増やしていくということがまあ対応できるんで、まあ、 そういった形で増えてきた仮想マシンに対して、ロードバランサーで負荷分散すると、
82:29 まあこれが一つの。考。え方ですね。
82:33 で、これ、図の中にあるアベイラビリティゾーンというものがあります。 もうちょっと注目してみてみましょう。アベイラビリティゾーンこれはですね、
82:42 まあリージョンはまたがない。まあすなわち東日本とか西日本とか、 リージョンはまたがないんですけれども、まあお互いがまあ比較的近距離で、
82:51 まあ異なるデータセンターとして、まあ配置されているものになってきます。
82:57 なので、まあ、この複数ゾーンまたいで、まあ仮想マシン配置しておくと、 まあ負荷分散ができるということに加えて、
83:04 まあデータセンターレベルでまあ障害が起きましたよという場合、 その障害リスクの回避ということもできることになります。で、
83:12 仮想マシンスケールセットこちらを利用するとですね、結構あの頭が良くて、 ちょうどこのアベイラビリティゾーンまたぐ形で仮想マシン増やしますという設定もできるということになります。
83:25 そうするとゾーンをまたいで、異なるデータセンターに負荷分散であるとか、 まあ分散する仮想マシン配置できますんで、なのでまあ
83:35 障害対応とかもだいぶやりやすくなるということになります。まあデータセンター、まあ、 障害発生した場合はどうなるかなんですけれども、まあ通信はまあ相変わらず、
83:47 もうずっとずっと入ってきます。Azureにどんどん通信は入ってくる状態です。
83:52 でも、例えばアベイラビーティゾーン一、使えなくなっちゃいましたという場合、 ロードバランスはですね、えっと、常にまあ、
83:59 通信できますかとチェックはしているんですね。なので、もしアベイラビーティゾーンあ、 なんか落ちちゃってるなというのが分かった場合は、じゃあ通信は一旦
84:08 このアベラビーティゾーンの仮想マシンたちに振り分けようかというふうに、 ここでまあ判断はしてくれます。なので、まあ、こういった形で
84:16 ちゃんとルーティングしてくれ。るよ。うになっているということですね、
84:21 なので、まあ、ゾーンまたいで、仮想マシン配置するというふうに設定をしておれば、 まあ基本的には障害ないところに利用できるというふうになっていきますんで、
84:31 接続は生きたままにできるということになります。そしてまあ図の方に、 まあちょっと下の方に書いてはいるんですけれども、共有ディスク用意しておくと、
84:40 その場合、同じディスクのデータというものを複数の仮想マシン、 参照できることになるので、まあ同じ状態で処理を引き継ぐとい。うことがで、
84:49 きます
84:55 ではですね、統合管理の観点についてを見ていきましょう。まず監視のサービスですね、 これAzureモニター、これはメトリックとかログ収集とか行うものですね。まあ、
85:05 問題有無を見極めるためのデータを蓄積していくという場所です。で、 アップデートマネージャー更新管理ですね。定期的な更新を行いますよ、
85:14 という場合に使っていきます。で、チェンジトラッキングとインベントリー。
85:19 これまあ変更の管理ですね。まあ重要な変更は記録されて、まあ後の、 まあ監査とか分析とか、そういったものに備えます。そしてAzure policy、
85:28 これまあガバナンスに関することまあ、 リソース構成の標準化やポリシーコンプライアンスの強制といったところですね。
85:35 まあ特にまあ、セキュリティとかガバナンスとか、 そういった面で守ってほしいルールこれがある場合は、まあ、
85:42 それらを強制適用されるようにするということが重要になってきます。 その際に使えるということですね。
85:49 ディフェンダー、フォークラウド、セキュリティ体制管理や脅威保護ですが、 こちらのセキュリティの講座、午後の講座で見ていきます。
85:58 これはもう軽く触れておきますね。では、データ保護とbcdrについて、 これも見ていきます。これはまあ、主なサービスがまあAzureのバックアップ、
86:09 それからAzureのサイトリカバリーですね。これらは主要なサービスです。
86:16 バックアップの方はですね、これはあの主にデータの損失からの復旧、 まあデータにフォーカスしたものになっています。一方でサイトリカバリー、
86:25 これはあのレプリケーションを行う仮想マシンのレプリケーションを行うということになるので、まあ仮想マシンの構成とか、そういった部分の再現もできるということになります。まあ構成とかもまあ含めて、まあ複製して備えられることになるので、まあダウンタイムとかもまあ短くなるということですね。
86:45 まあ、 わざわざなんかソフトウェアインストールとかそういったところから再開しなくても良いということになります。そして5つ目、AIによる運用支援。これもまあ簡単に見ておきますね。Microsoft
87:01 Copilotインナージュを活用できるということになりますが、 まあ様々なタスクAIベースで支援してもらいというものですね。
87:12 自然言語での対話、もうこれが生成AIの一番の特徴ですね。これ、 可能になるということです。で、設計支援からトラブルシューティングまで、
87:21 これは開発のライフサイクルも全面的にサポートしてくれるという機能になっています。で、 それから学習支援ですね。まあ、何かわからないことがあったら、
87:31 とりあえず聞いてみるという運用が可能になります。まあ簡単ですが、 ここで本節のまとめです。
87:39 Azureで変わる運用とセキュリティ対策、これらを学んできました。まあ、 セキュリティ面はあの別口座で取り扱うんですけども、まあ、
87:49 運用管理面の基本的な考え方をここで見てまいりました。はい、では。 ブイエムアイ環境の移行について、これをここでは見ていきたいと思います。
88:00 ブイエムアイ環境のスムーズな移行ですね。ここではまあ、 主にAzureブイエムウェアソリューション、これを元にした。
88:09 移行のあり方を考えていきたいと思います。もしですね、 オンプレイでブイエムウェア環境が実行されているという場合はですね、まあ、
88:18 あのAzureブイエムウェアソリューションへの移行、 これがもう一番あの簡単な方法です。
88:24 このAzureブイエムウェアソリューションなんですけれども、これは まあ専用の専用設計のマシンにありまして、
88:32 これを使ってプライベートクラウド提供するというようなものです。
88:37 本当にはですね、あの最低限の労力で意向を実現できるし、さらにあの特典とかもですね、 活用していくと、まあ運用負荷に加えて、
88:46 まあコスト削減にもつなげられる可能性があるというものですね。加えて、まあ、 Azure service、Azure serviceとの連携も可能になっています。
88:56 まあ特にですね、あの構成にほぼほぼあの手を加えずに移行できるので、まあ、 あのVMウェアをもうすでに使用してるんですという場合は、もうまず第一に。
89:06 検討すべきソリューションであるということになります。で、 このVMやソリューションの概念、これもちょっとだけ見ておきたいなと思います。
89:16 左側オンプレ、右側Azureでこのオンプレの中に ブイスフィアクラスターってやつがありますね。ブイスフィアクラスター、
89:26 これがオンプレと、あとAzureの方にもありますね。
89:31 このボイスフィアクラスターなんですが、これはまあああ、複数ホスト、 一つのホストのように、まあ扱えるような、まあそういった、まあ環境であるとまあ、
89:40 ざっくり一旦が表現しております。そしてhcx、 これはあの移行のためのツールですね、そしてこのhcxを使うことで、
89:48 まあほぼそのまま VMアンソーションのクラウドに移すことができるということになります。
89:53 ほぼそのままですねボイスフィアクラスターからボイスフィアクラスター、まあ、 ほぼそのままということ、になります
90:01 で、その後、まあ専用の、まあ仮想ネットワークとか、 これを通じて他のAzureリソースと接続ができるということになります。
90:12 非常に簡単にAzureへリフトするということが可能になるということですね。で、 このhcxによる移行について、これも簡単に確認をしておきましょう。
90:26 Hcxはですね、これはまあエルツーエンシンであったりとか、 あるいは仮想マシンの移行のツールという形で使用ができます。で、
90:36 この移行の方式なんですが、これはあのダウンタイムの要件ですね、 これに応じて選択することになります。これは特に移行の計画、
90:45 練るときに問題になる部分、まあ検討すべき部分になってきますんで、 これはちょっと見ておこうかなと思いますまずですね、仮想マシン。
90:55 停止しても良いですという場合、これはコールドマイグレーションですね。 一定時間停止しても大丈夫ですっていうのは、もう一番要件としては緩いことになります。
91:05 なんでまあ可能であれば、これやるともう簡単に、 まあ緩い要件で移行ができるということになります。で、
91:12 あんまり長い時間はダメなんだけれど、 まあごくわずかだったらまあ大丈夫かなという場合は、
91:17 バルクマイグレーションが適しています。
91:21 これは、これはですね、最初に移行先にレプリケーション複製行っておくんですね。 そうすると移行元がまず停止します。その後、瞬時に移行先が起動しますと、
91:31 そういう形で移行を操作を行うということができます。で、 無停止が要件にあるもうサービスは、
91:37 まあ例えば基幹システムとかもそうかもしれませんけども、無停止が要件ですという場合は、 ブイモーションライブもライブマイグレーション。これが後方になってきます。
91:47 ただまあブイモーションこれ自体。はですね、まあ基本的には
91:51 1台ずつの移行がああ、そういったようなもので、 まあハードホックな移行をするようなものです。なので、まあ、
91:59 たくさんあるといえばちょっと他に検討する必要が出てきます。で、まあ、 無停止が要件なんだけども。まあ、大量の仮想マシン変更が必要であるという場合は、
92:10 このレプリケーションアシステッドvモーション、これを検討するということもあり得ます。
92:17 これはですね、まあ、あのvモーションとバルクマニュレーション、 組み合わせたようなものとなっているんですが、まあこれは
92:24 バルクマニュレーションのように最初に複製を行うということですね。その上で、 vモーションを使用するということになります。
92:32 これちょっとだけまあvモーションでの移行やりやすくなるという側面があります。まあ、 これら移行の方式はですね。まあ、
92:38 移行プロジェクトとしてどれか一つだけを選ぶというんじゃなくて、まあ仮想マ。シン。 ごとに
92:44 まあ、適切な方式を選ぶことがまあ重要かなと思います。そして、エルツーエンシン。 これもですね、えっと、後で少し触れていくんですが、まあ、
92:53 ここでも少しだけ触れておきましょう。エルツーエンシンこれは オンプレとAzureでアイピーアドレスの枠組みをまあいわば共有するというような仕組みですね。なので、まあ一部はAzureに移行しました、一部はオンプレに残しますという場合に、まあ、それぞれが同じ。まあ、アイピー空間で。
93:13 通信を行うという仕組み、これをまあ、一応取ることができるということですね。 これは後で少しだけ触れていきます。で、移行にあたってはですね、
93:24 まあコストの議論、これは避けて通れないというものになっております。で、 ブイエムエアソリューションのコスト、これはまあ主にですね、ホストのタイプと数、
93:37 それから稼働時間で決まってきます。
93:40 で、それに加えて、まああのハイブリッド特典であるとか、 こういった割引も考慮していくということになりますね。あとまあ追加で
93:49 無償の拡張セキュリティ、更新プログラム、 これも提供されるということになりますね。まあ、
93:55 サポート期限切れがまあクラウド以降のモチベーションなんですよというケースでは、 こういったものもメリットに組み入れられるかなと思います。まあ特にですね。まあ、
94:06 ハイブリッド特典あるということは、まあ重要かもしれ。ま。せ。ん。
94:10 まあ、仮想マシンの移行ができるんで、するとまあただそれだけだと、まあなかなか。 差別化にはつながらないことがあるかもしれないんですが、まあ、こういった特典あると、
94:21 コストの部分で、まあAzure以降、 まあ強力なインセンティブになるんじゃないかなと思います。そしてあと参考程度にですね、
94:29 こちらニューパニックスクラウドクラスターソンAzureについてご紹介をしております。
94:36 まあニュータニックスはですね、あの仮想環境実行に必要なサーバーとか、 ストレージそれからネットワークの機能とか、これを統合した製品です。
94:44 このエイチシーアイハイパーコンバージョンインフラなんていうふうに言われたりもしますけれども、それを提供している企業様ですね。で、まあ、あの従来のサーバー環境、これ、あのスケールさせるの難しいんですね。スケールさせるためにはオンブレイソルをスケールさせるためにはサーバー購入します。ストレージ購入。しますネットワーク機器も購入します。もう全部対応が必要なのでちょっ、と複雑だと
95:06 いうことがあるんですが、まあ等式使えばまあ割とオンプレでもちょっと 仮想実行環境スケールしたりとか管理とかしやすくなるということなんですね。
95:14 なんでまあそういう点で。こういったエッチシーアイ、 まあ人気があるという製品です。で、それをまあ、ソフト、このニュータニックさん、
95:22 ソフトウェア、Azureのインフラ上で実行できるので、 まあニュータニックスユーザーもAzureに移行しやすいんだということがここで書かれております。
95:34 では、本節のまとめです。あ、VMAの移行方法これを学んできました。 で、移行のオプションですね。まあ、四つありましたけれども、複数あったので、
95:48 まあ要件に応じて選べるようにしていきましょう。というわけで、 本章のまとめですこれら三つの要素を確認してきました。ああ、こういった。
96:01 基本的な要素技術ですね。
96:04 それから、クラウド移行後、運用管理点で得られるメリットなんだったでしょうか。 そして、特に仮想環境を運用している場合に、まあ、
96:18 どういった移行パターンがあるんだということ、これも確認をしてまいりました。 それぞれ大丈夫でしょうか？それではですね。
96:31 今回はこのまま第三章の方に進んでまいります。第三章。
96:37 意向とクラウド活用の応用編ということで、今回はまあ技術の 詳細もビニーさんにいるような説明というものは、今回は行わないんですけれども、ただ、
96:48 クラウド移行のコンセプト、これを構想するために必要な考え方であるとか、 あるいは部分的な意向だとか、そういったものに関する考え方を紹介していきます。
97:00 目、次はこちらですね。見ていきましょう。
97:03 キャフト和風、これはそれぞれフレームワークですね。まあ、 プランの移行のプランとかをレビューする際に、
97:11 その思考を助けてくれるというものになっております。そしてAzureマイブレット。 これはAzureマイブレットのまあ、シンプルな利用シーンだけ？
97:22 簡単に紹介します。そしてオンプレとAzureの連携ですね。まあ三つの連携方法、 これを例としてご紹介いたします。
97:32 そして、アダプティブクラウドアプローチこれ AzureのアークロしてAzureローカルの概要を紹介します。まあ、
97:41 オンプレとかのリソースをですね、 Azure上のリソースであるかのように取り扱うという方法ですねを紹介していきます。
97:50 そして、情報収集の方法について、こちらもごく簡単に言及していきますね。で、 本書の概要はこちらです。ここは図の通り。
98:01 なんですけれども、まずですね。移行がそもそも本当に必要なんですかとか、 そういった検討も含めたプランニングを行って、で、移行する場合は、
98:12 それをどういう形で移行するべきか、 どういう形で実施するべきかっていうのを決めていくというのは、
98:20 本章のテーマになっていきます。で、この商店はですね、もう多様な。 ああ製品を取り扱っていきます。
98:29 で、まあ、ここにあるのも、まあ割とあのごく一部に過ぎないんですけれども。まあ、 これは説を追って、少しずつ確認をしていきましょう。では、
98:42 初めに移行を計画する際に必要な考え方、 これをフレームワークという形で学んでいきます。キャフそれからお和風ですね。で、
98:54 キャフと和風。これ何かなんですけれども。
98:58 これはイラストで示すようにですね。これはガイドラインであるとか、 あるいはガイドブックのように使えるフレームワークですね。
99:06 もう右も左もわからんぞという指針もない状態だと、 もう良し悪しの判断できなくなっちゃうんですね。難しいと良し悪しの判断、
99:14 難しいとそういう状況にならないようにするために、まあ、 こういったフレームワークを使うと良いですねということです。では、
99:22 少しずつ内容を見ていきましょう。キャフとワフまずキャフからいきましょう。
99:26 キャフクラウドアドプションフレームワーククラウド導入ですね。 クラウド導入に関する活動全体をカバーするフレームワークです。ここでまあ、
99:37 地図というふうに表現しているように、まあ、向かうべき場所を見極めるためのものだと、 ここでは一旦考えましょう。そして和風の方はですね、
99:48 和風ベルアーティテクテッドフレームワーク。
99:51 これはですね、設計の、まあレビューとかの際に使える観点、 これをまとめたものですね。で、点検表というふうに表現されているように、
100:00 考慮するべき項目がもう実際に考慮されてますか？と、 これチェックする場合の観点が整備されています。これらはですね、まあ、
100:09 ここでちょっと書いているんですけれども。
100:13 必ずしも技術者、開発者だけではなくて、 ビジネスの担当者もまあできるだけ活用することが望ましいというふうにされております。
100:23 まあ、 こういったフレームワークを使ってクラウド導入を成功させていきましょうということですね。で、まずはえキャフを見ていきましょう。ここでは六つの項目をピックアップして挙げております。
100:41 見ていくとまあ、1から4ですね。戦略策定から導入まで、 これは順を追ってクリアしていくステップになっています。戦略策定、
100:50 まずはどこに向かえばいいんですか？そして計画、あそこに どのようにすればたどり着けますか、そして準備、まあそれは踏めて、
101:00 まあ支度をしますと計画を踏まえて支度します。そして導入、 まあ実際にそこへ向かいますということですね。
101:10 そして5から6、これはまあ、計画以降のステップで、 まあ適宜組み入れていくステップかなと思います。ガバナンスと管理、これらはですね、
101:22 まあいわばまあ問題が発生しづらい体制づくりであるとか、 あるいは問題発生時の備えを進めていくものだと考えればいいかなと思います。で、
101:33 次は和風。ですね、こちらを見ていきましょう。和風。
101:39 これは五つの観点、五つのカテゴリーがあります。まあ、 これらレビューの観点はですね。
101:44 まあ割とあの実際に実務されている方からすれば基本的なものかもしれないんですが、 まあ本当にどのような場合でも考えるべきものかなとあります。
101:54 まあ実際こうやって一覧にしてみるとですね、 まあ割とたくさんあるなあという感じなんですが、
102:00 もしかしたらもうちょっと全部覚えるというのは大変かもしれないです。なので、まあ、 実際に個別要件検討するという時に。
102:08 五つの観点をブレイクダウンして、 まあこれらにたどり着けるようにしておくと良いかなと思います。で、
102:15 まあ場合によってはそのブレイクダウンする際にですね、まあ生成AIコパイロットとか、 まあ使うとまあ効果的に観点具体化していけるんじゃないかなと思います。え、
102:26 それぞれまあ簡単に見ておきましょう。一つ目はえ、信頼性ですね。 まあすなわち使える状態を維持できるようになってますか？という観点で2つ目。これ、
102:36 パフォーマンス効率ですね。
102:38 遅くなったりせずに、目標時間内にジョブでタスク完了できますか？という観点。 そして3つ目はセキュリティですね。システムが脅威から保護されていますか？という観点。
102:50 そして4つ目はコストの最適化ですね。適切なコストとそれに見合う価値、 ちゃんと得られてますかという観点。そして5つ目ですね。
102:59 これはオペレーショナルエクセルやつ。まあ、ちょっと難しい概念かもしれませんが。
103:05 まあ変更が適正であるか。まあそれを保証して、 その上で運用が効率的に行われていますかという観点ですね。このあの五つの項目、
103:15 これをブレイクダウンした上で、レビュー項目というものを作っていって、 レビューするっていうことになっていきます。で、
103:25 キャフヤー風これをまあ目的を体現したリソースまあたくさん。 公開されておりますんで、まあ必要に応じ参照をしてください。
103:39 普段は全部は紹介しないんですけれども、まあ例として、キャフの具体例として、 まあエンタープライズ規模のランディングゾーンっていうものがあります。
103:48 ランディングゾーンはまあ少し後で取り上げるんですけれども、 まあベストプラクティスですね。理想のベストプラクティスを反映した具体的なもの、
103:57 具体的な構成、図みたいなものです。そしてまあ和風の具体例、まあ、 和風レビューというものをここで紹介しておりますが、まあ60問。
104:05 セルフ診断というふうに書いておりますけれども、まあ、 60問のこの設問に答えると、あ、
104:12 あんたはどこに力を入れて対応するべきですとアドバイスをくれるというものになっています。で、ここでですね、キャフトアフ。まあ二つ分けて紹介してきましたが、ここであの二つをつなげて考えていきましょう。キャフではフェーズ分け行っていました。
104:30 で、そのフェーズごとに、まあ和風をもとにするレビューをどう行うか、 ここでまとめております。まあ簡単にですが見ておきましょう。
104:41 計画段階ここでは移行するものが決まりましたという場合に、 クラウド側の構成証するリソース過不足や問題ないですか？
104:50 というものをチェックする準備段階では、これはまあ実装内容ですね。 実装内容が決まった時に。
104:58 アーキテクチャ問題ないですかというのをレビューする。そしてまあ導入段階ですね、 まあ、移行作業が終わったとしまして、
105:07 まあ稼働を開始する直前前に品質保証を行うというためのレビューですね、 こういったものがあります。で、管理工程ですと、パフォーマンスの測定とか、
105:18 これを行って、まあ継続的に改善をするということがあります。これについてはですね、 もうここに書いてある通り、まあ四半期ごととか。
105:28 いうふうに書いてありますが、もう常にループを回す、 改善を続けるということが重要です。1回
105:36 改善のためのループ回した終了ということではなく、 もうずっとずっと行っておく必要があるということですね。で、
105:44 ここからはランディングゾーンについて見ておこうと思います。 ランディングゾーン何かなんですけれども。
105:52 このランディングゾーン企画や設計した内容ですね。 リコーン企画設計した内容ですが、これをアジルでの実装に落とし込んだものです。まあ、
106:02 実際に移行先であるクラウドでその設計内容にの、まあ着地点ですね、 設計内容の着地点を示したものと考えます。Microsoftではですね、
106:11 その実装のベストプラクティスにあたるもの、 これをランディングゾーンとして公開しているんですね。
106:20 このランディングゾーンまあ、定義としては、まあ、 ここで標準的な環境としておりますけれども、まあ要は
106:27 ベストプラクティスですね。これを反映した、 実際の設計であるというふうにお考えくださいえ、そしてこれはあのアイエーシーですね。
106:35 この後に見ていきますが、そのコードとして利用できるようになっています。そのため、 そのコードを使って、まあ、
106:42 手早く実際にデプロイドすることができるようにもなっています。
106:48 このランディングゾーンですね。まあ設計にあたって こういうことを考えましたという、まあ設計領域がありますけれども、まあ、これちょっと。
106:57 簡単に紹介しておきましょう。ランディングゾーン八つあるんですが、 これ左側ですね。左半分がまあだいたいAzure環境の管理に関する内容ですね。
107:08 全体的な環境セットアップに影響するようなものたちが、 ここら辺で提供されていると。
107:16 そして右半分。これはコンプライアンスとかガバナンスとかに。 関連する内部です。まあ、規制であるとかルールであるとか、
107:25 こういったものをどう守るかという観点で作られたものたちですね。 こういった設計領域に配慮して、まあ設計、そして実装が進められるということになります。
107:40 ここでですね。全ページで少し見てきたんですけれども、まあ、 iacについて簡単に見ておこうかなと思います。iacですね。
107:49 これはインフラ構成をコードで定義管理するというものになっています。 これはもう今日のクラウドシステム開発ではですね、
107:57 もうほぼほぼ必須というものになっています。
108:03 まあ実用性としてはですね、まあ、 あのコードを使用して同じ構成をぬくもれなく再現できるという点が挙げられます。で、
108:12 そしてデプロイがまあ手作業じゃないので、まあ時間も短縮ができます。そしてまあ、 管理面で言うとコードで管理できるので、
108:21 まあリットとかこういったリポジトリで管理できるので、変更も追跡ができます。 そしてコードであるということは再利用もしやすいです。
108:34 逆にですね、これらを使わない場合、あのコマンドラインツールとか、まあ例えば、 あるいはAzureポーターですね。こういったもので、
108:42 まあ一つずつ操作をするということになってしまいます。特にAzureポーターとか、 こういった画面使って、ポチポチポチッとマウスポチポチッとやるもの。
108:51 ちょっと皮肉めいた言葉ですけど、 クリックオプスだっていうふうに言われることもあります。
108:56 こういったクリックオプスとかやってると、もう確実にミスが起きちゃうんですね。で。 大きなシステムであるほどこういったあの
109:03 ポータルとか管理とかは普通はもう行われません。ちゃんとコードで管理します。で、まあ、 お客様が移行するという場合も、
109:12 多くの場合はそれなりの大きさを保ったシステムを移行するということになるので、 おそらくはこのiac、活用することになるんじゃないかなと思います。これは
109:24 本節のまとめです。本節ではキャフと和風、これらを扱ってきました。
109:30 これらフレームワークですんで、まあ提案とか計画を練る際に、まあ、 これ本当に大丈夫かな？という時にも活用できるものがある。
109:41 それをチェックするべきに活用できるものがあるということを知っておくといいでしょう。 では、次はAzureマイグレートですね。まあ、
109:51 いわば移行のアシスタントみたいな役割があるのが、 このAzureマイグレートですね。
110:00 まあこの章ではまあそこまで詳細に当たるところまで確認せずに、 まあ概要レベルで見ていこうと思います。
110:09 このAzureマイブレットなんですが。これ名前が示す通りマイブレット。これ、 あの移行という意味ですね。マイブレット移行なんですが、
110:20 ただ本当に移行のための操作だけを行うというわけではありません。
110:25 まずですね、オンプレイでリソースをまず検出するという操作を行います。 ここでまあインベントリーの検出というふうに表現されたもするんですけれども、まあ、
110:36 その検出したインベントリー、これを評価して、評価することで、 まあ適切な移行先のAzureリソース方法、これを選定してくれるということも、
110:46 やってくれます。まあその上で、 まあ実際の移行まで責任もって行うということになってまいります。
110:57 なんでまあ、移行とはついているんですけども、移行の準備段階ですね。 準備段階と行うことを一通りカバーしてくれるということになります。そして、
111:09 このAzureマイブレートによる移行の手順についてなんですが、これは 概ねこのスライドの通りです。まず初めに何を移行するのかというものをまとめる。
111:21 まあ、インベントリの作成ですね。何を移行するんですかというのをまとめていく。
111:29 その次に、まあコストの資産ですね。まあ、ここを結構重要ですよね。まあ、 コストメリットがないんだったら、オンプレを継続するということも大いにありえます。
111:38 そして、アプリの依存関係のマッピング。 これまあちょっとわかりにくい表現かもしれないんですが、これはまあ、
111:45 言ってみればですね、業務のアプリケーション同士が連携して動いているという場合に、 それらの依存関係を明らかにするという工程です。
111:54 なので、今、例えば、 あるサービスのIPとまあ別のサービスのIPがどうもネットワーク内にやり取りをしているらしいということが、まあ評価時にわかるので、まあそうした情報をものにして、依存関係を導き出すということになります。これら踏まえて移行計画を作成して、その後、まあいきなり、移行するというんではなくて、入念にテストをしていきます。そしてテストをしてからようやく移行に進んでいきますという。
112:23 まあ、こういった形で手順が踏まえていきます。まあ、 Azureマイグレートを使うと、こういった。ああ、
112:30 移行計画練る際に必要な情報をうまく収集してくれるという側面があるんですね。 なのでまあ移行の際、計画を立てるという際には、
112:39 ぜひこのAzureマイグレートを使うというということになります。そしてまあ、 あの本節短いんですけれども、まとめと入っていきますで、Azureマイグレート。
112:51 担当できる範囲確認してきました。まあ、移行だけではないですね。 移行するものだけではないですね。
112:58 インベントリーの検出から担当できるということをまず理解しておくと良いかなと思います。 え、次はですね、えっと、オンプレとAzureの連携について見ていきましょう。
113:10 まあ、すべてをAzureに移行するんじゃなくて、 まあうまく連携するということが有効なケースもあります。
113:19 この連携の例っていうのをいくつか紹介しておきましょう。で、イラストではですね、 この人がちょっとディスクがもうないな、
113:26 足りないなというふうに困っている状況が利用されております。まあ、こういった場合には、 まあストレージオイルの拡張というユースケースがビタッと当てはまるんですけれども、
113:37 まあ、ここではまあそのケースと、あともう一つ、あ、もう二つ、災害対策と、 あとまあアイピーを維持した状態の移行、これらについて見ていきます。
113:49 で、ここで挙げる三つの事例の概要がこちらです。 一つはハイブリッドのファイルサーバーですね。これを作っていこうということ。まあ、
113:59 これはもうあのシンプルに容量制限なくせるというのは非常に大きいメリットです。で、 2つ目は災害対策ですね。バックアップは必要なことではあるんですけれども、まあ運良く、
114:13 幸いにもそれは全く使わないということもありますね。
114:17 で、これ、オンプレの場合、そのためにインフラ投資するっていうのは、 どうしても気持ちとしてはちょっともったいなかったかなという気持ちはどうしても発生するんです。必要なことであったとして。なのでまあ、クラウドへバックアップするということで、コストを最適化できる余地があるということになります。で、3つ目は簡易的エルツーエンジンですね。まあ、一時的にクラウドとオンプレをあたかも同一のネットワークであるかのように扱います。
114:44 先ほども少し触れていきましたけれども、 ここではまたもう一度内容を触れていこうと思います。で、
114:51 ハイブリッドファイルサーバーの例ですね。まあ、主に利用するAzureサービス、 これはAzure filesですね。Azure files、
114:59 ここにファイルをオンプレから同期していくんですけれども、 オンプレから同期をしていくんですけれども、
115:06 その際に同期するためにAzure file syncというものを前に置いてます。
115:13 クライアントはですね、 いつも通りウィンドウズサーバーにアクセスしてファイルを利用しますが、
115:18 まあ裏ではですね、 このウィンドウズサーバーがAzureファイルシンクと同期をしているということになります。ただですね、同期しているだけだと、まあ、バックアップとあんまり変わらないというふうになるかなと思います。なので、このウィンドウズサーバーの役割はですね、まあ、いわばキャッシュしているような役割です。すべてのデータを保持しているんじゃなく。て。まあ、キャッシュ機能とかをするまあ中間役になっているということですね、
115:43 頻繁にアクセスされるものが、ファイルがあったら、 それはもうウインドウズサーバー内に置いておく。あんまりアクセスされないなとなったら、
115:52 もうそれはAzure上に置いておくという運用をするという構成です。あ、失礼。あ、 はい。で、災害対策の例についても見ていきましょう。主に利用するのは、
116:03 このAzureバックアップ、そしてAzureサイトリカバリーです。これは 先ほども見てきましたね。
116:11 で、 あとまあそれらを保管するものとしてリカバリーサービシリーズボートというものもあります。バックアップはですね、まあ、先ほどもう少し触れたんですけども、バックアップはまあデータを複製するもの、そしてサイトリカバリーは仮想マシンのレプリケーションを行うというものでした。まあここではですね、まあ特にまあデータもバックアップするし、仮想マシンもバックアップすると。
116:39 両方バックアップするんだという点がポイントになるかなと思います。まあ、 データとそれを処理するサービス二つが揃うことで、
116:48 まあようやくまあ業務をスムーズに再開できるというわけですんで、 まあこのバックアップという場合も、まあデータのデータそれからサービス。まあ、
116:59 両方ともリカバリーできるようにしておくということが重要かなと思います。 そして簡易的エルツーエンジンですね。
117:08 これも少し見ていきましょう。エルツーですね。 これはレイヤー2Dayタリンク層を指しています。これはですね、
117:17 まあオンプレのサブネットとAzureのサブネット、これがまあ、 あたかも同一のネットワークであるかのように扱います。え、
117:26 これまあ何が嬉しいのかなんですけれども、まあ、え、そうですね、ユースケースとしては。 例えば、移行作業を行いました、オンプレから。
117:37 Azureにサーバーを移行しました。ただですね、移行したんですけれども、 移行先で一部のアプリケーションを扱うマシンが、移行先でエラーになっちゃいました。
117:47 ただですね、そのエラーが出たマシンというのは、エラーが出たマシンで、 提供されるサービスっていうのは、他のサービスから使われている。なので、
117:57 他のサービスが業務を続行するためには、 そのエラーが出たマシンも生きていなければいけないということになります。
118:05 あと、継続業務続行できなくなるんじゃないかなということになってしまうんですけれども、 そうした場合に、
118:12 例えばエルツー電信を使用して一時的にオンプレの移行元サービスを稼働させておくということもやり方としては考えられます。そうすると、移行後のサービスですね。移行後のサービスがエルツー電子に使うことで、移行前のサービス、オンプレ上のサービスを利用できるということも考えられます。なので、まあ、もし何かそういったことが発生した場？合。
118:36 まあ、こういった対応を一時的に取るということも可能であるということになります。 ただですね、この運用をずっと継続するっていうことは、
118:45 あの必ずしも望ましいものではありません。まあ、 どうしてもあの構成が複雑になってしまうんですね。あと、
118:52 ネットワークが本質的には違う場所にありますんで、 それがボトルネックになってしまうということもありえます。
119:00 常なで、あくまで、 まあ一時的な利用にとどめるということは望ましいんじゃないかなということですね。
119:08 ここはまあ、注意点として押さえておきましょう。では、本節のまとめです。まあ、 コンプレとAzureの連携で三つを確認してきました。オンプレを拡張する。
119:21 オンプレの障害に備える。 それから一時的にでもクラウドとオンプレを同一のものに見せかける。
119:30 まあ、こうした例を紹介してきました。え、次はえ、 アダプティブクラウドアプローチについてですね、これを見ておきましょう。え、
119:39 ここまでですね、移行がメインテーマで続けてきたんですけれども、ここではですね、 オンプレートクラウドのハイブリッド、
119:49 あるいはAzure以外のえパブリッククラウドを使用するという場合について考えていきます。アダプティブクラウドとは何か？
119:58 なんですか、このアダプティブクラウド。これはですね、まあオンプレイとか、 あるいはAzure以外のクラウドとか、これ、
120:06 こういったAzure外のリソースもAzureで管理するというためのアプローチを指しています。まあ例えばですね、まあポリシーに従ったセキュリティであるとか、まあガバナンスであるとか、こういったものを維持する上で、まあ重要なコンセプトになっています。それですね、まあ。
120:24 Azureの例えばですね、Azureのセキュリティ、しっかりします。 もうちゃんともう計画もしました。完璧な体制、Azure上で整いました。でも、
120:33 Azure街のことはわからないです。 Azure街のことは知りません他のクラウド知りませんってなってしまうと、
120:40 トータルで見て、 組織全体のセキュリティとかガバナンス維持されているとはとてもとても言えないということになるんですね。となると、まあ、Azureに完全移行したいなというふうになって。し。まうかもしれないんですけれども
120:53 ただ、 それでもAzureで全部管理するということは合理的ではないなというケースもありえます。そういった場合に、オンプレとか他社クラウドを維持しつつも、関連に操作をできるだけAzureから統合管理できるというふうにする方針がベターになります。ここでは関連するサービスとして、Azure
121:15 Ark、それからAzure local、これを取り扱っていきましょう。
121:22 Azureワークはですね、これもうとにかく導入が簡単なものですね。まあ、 エージェントと呼ばれる軽量なプログラム、これを管理対象に導入すればオーケーです。
121:32 そしたらもうそのエージェントがですね、例えばリソースのID、これですとか、 そういったID発行ですとか、管理下に置くために必要な処理、
121:41 これをその軽量プログラムのエージェントが行ってくれるということになります。
121:48 そしてAzure local。これはまあ主に仮想環境を想定したものかなと。まあ、 既存のオンプレイ基盤、これをAzureのサービスのように、
121:59 まあみなすためのものだと考えればいいかなと思います。で、一つずつ見ていきましょう。 まずAzure Arkについてですね、これはですね、まあ主要な用途として、
122:11 まあWindowsとかLinuxのサーバーに導入して、まあそれらを。
122:16 まあ、Azureのリソースとして管理できるというようにすることですね。 そうするとまあ、様々なAzureリソース向けの監視サービス、
122:26 これらが適用できるということになります。まあここまあすごくたくさん。 図では表現されてますが、
122:33 まあこういったサービス監視系のサービスインプレに対しても使えるということになってきます。まあ他にもですね、えっと、Kubernetes使うとか。
122:44 まあ、そういった高度な構成にも対応をしております。あとまあ、一部のサービス、 Azureサービスについては、
122:53 まあアーク経由でインプレ上の管理リソースが管理リソースを管理するということもできるようになっております。割とシンプルな例ですね。そして、Azure localについてこちらまあ旧称にまあhciと。
123:12 入っていることからも伺えるかもしれないんですけれども、まあ、 あの仮想環境に関連するサービスとなっています。ここではですね、
123:21 オンプレの環境上で、まあ、この仮想環境、実行用のまあ構成が行われています。で、 この仮想環境上で、まあ、仮想クバンテスとか、あるいはまあ、
123:32 ここにある仮想デスクトップとか、まあ、いろんなサービスが展開されているとしています。
123:41 ポイントはですね。このAzure local、こうしたローカル。 オンプレの環境を、
123:47 これAzureアークを介してAzure上から制御できるようになるということですね。 なので、まあ、オンプレ上の環境維持が合理的ですという場合でも、
123:57 このアダプティブクラウドのアプローチ使うことで、 Azure上をもう管理の窓口にとして、使えるということになります。まあ、
124:06 負担原理ですね、管理の負担が減るということになります。
124:11 まあ、加えて統一されたポリシーを運用するといったことも可能になってきます。 マクラウド上のリソース管理、それからローカルの環境管理、
124:22 これを独立して行うというのは、やっぱり大変なんですね。すごく難しいですし、 絶対に設定の齟齬であるとか、あるいは適用漏れとか、
124:32 そういった問題が起きる可能性があるんですね。なので、 もうとにかくポリシーたくさんあるんです。
124:40 でもそれを適用するのは問題です。ということは、 生じた場合にこういった一元管理するっていう考え方のソリューションたちを使うと、
124:49 まあ非常に効果的に管理ができるということになります。ではですね、 ここでまとめに入ります。ここではですね、
124:58 アダプティブクラウドアプローチについて取り上げました。まあ、 オンプレイ運用であったりとか、あるいはまあ他社のクラウド利用、
125:07 これをまあ部分的に継続するっていうことが必要ですという場合。で。も。
125:12 管理はAzure上で一元化する。そうすることで、まあ管理効率高まるんですね。なので、 まあ、今回移行トピックにしてはいるんですけれども、
125:21 まあ提案する際もとにかく全部クラウドに持っていきましょうよという提案をするんじゃなくて、まあ場合によってはですね、オンプレの方が合理的だということもあるかもしれないんで、その場合でもこういうアダプティブクラウドアプローチあるんですよというふうに案内しておくと、効果的かな。と。思います
125:45 では本郷さん、最後になりますけれども、 Azureに関する情報収集について取り上げていきたいなと思います。で、
125:53 Azureに関する情報収集、これはそうですね。まあ、 皆さんどういうところで情報収集されているでしょうか。まあ、
126:01 ツイッターとかもあるかもしれませんし、インターネット検索とかあるかもしれませんし、 あるいは公式のサイトを訪れているという人もいるかもしれないんですけれども。
126:13 ただですね、Azure関連の情報、もうとにかく情報たくさんあるんですね。 どこから調べればいいんだろうということになること、やはりあると思います。
126:24 なんで本節ではAzureに関する情報収集方法、簡単に ご紹介していきたいなと思います。まずですね。。
126:34 各種規制への対応についてこの場合はですね、サービストラストポータル、 これを使用すると良いということですね。
126:44 ここではまあいろんな規制に対応してますということが文書として提示がされております。 特にですね、えっと、大きな企業であるとか、あるいはまあ、
126:54 役員とかもそうですけど、規制の強い業界の企業の場合、とにかくコンプライアンス、 コンプライアンスだと禁止されることが多いんですね。で、その場合、
127:04 まあシステム開発するとなった場合に、それらに対応できないという場合。
127:09 場合によっては、もう提案のとかの段階で、 検討の余地なしですっていうことで足切りされてしまうというケースもあるかもしれません。
127:18 で、Azureはですね、まあ、多くの規制に対応していますが、ただ、 あのお客様からですね、
127:24 そのエビデンス提示してくださいというふうに要求されることはあるかなと思います。 そういった場合に、このサービストラストポータルを使うことで、
127:34 まあそういったああ情報を入手するということが可能となります。
127:39 まあ、とにかくですね、コンプラ的にまず大丈夫なんですから、こういった部分、 必ず質問を受けるという業界あるかと思いますんで、その場合、足切りをですね、
127:48 食らわないようにこういったサイトちゃんとあるんですよということを知っておくと良いでしょう。そしてスキル習得についてはですね、Microsoft Run、これが基本になります。まあ、多くの人もですね、
128:00 実際インターネット検索したらMicrosoft Runのサイトに行き着くんじゃないかなと思いますけれども。
128:07 このMicrosoft Run、 これが無料のオンライントレーニング基盤ということになります。まあ、
128:14 あの個別のドキュメントももちろんあるんですけれども、 それに加えてラーニングパスであるとか、
128:20 あるいはもう学習用のモジュールとか役割に応じて、 まあ学ぶべ学ぶべきスキルセットみたいなものが定義されていて、
128:27 それらを必要なものを順番に学習を進められるというふうになってるんですね。まあ、 学習をガイドする機能というものもあったりします。
128:37 ですので、そういった形でガイドされた学習というものを進めることで、 技術面の情報、まあ、ここでキャッチアップできるんだということになります。
128:46 なかなかドキュメントを読むだけだとですね、なかなか難しいと思うんですけれども、 こういったガイドされた学習モジュールうまく使うことで、まあ効率的に、
128:55 かつ体系的に知識を身につけるといったことが可能になります。で、 場合によってはですね、例えば少し前の章でも紹介しましたけれ。ど、
129:05 もコーパイロトであるとか
129:07 そういった生成AIと併用すると、まあ効果的かもしれません。まあ、どうしてもですね、 このドキュメント内容、かなり難しいことを言ってるなあという場合、その
129:15 その内容をコンパイオートに渡してやってですね、ちょっと解説してくれませんかね。 非技術者向けに解説してくれとかいうふうにすると、まあ、
129:23 結構わかりやすくドキュメントの内容を説明してくれることもあるかもしれません。で、 このMicrosoft Runを中心に、
129:30 いろんな学習をしておくとよいかな？と。思います
129:38 それ以外にですね。 新しい情報が公開されるということもあるかなと思います。ちょうど先月とかもですね、
129:45 まあ、大きなイベントありましたけれども、まあ、こういった新しい情報はですね、例えば、 あの公式のあサイト。いろいろありますね、
129:54 こちらを参考書にするとよいでしょうではAzureのブログですね、 公式のブログあります。まあ、新サービスの発表、昨日のアップデートで技術の解説、
130:03 事例紹介とか。
130:04 Azureに関する最新情報を発信しています。で、Azureのアップデートこれはまあ、 ちょっと技術よりの内容かもしれませんが、まあ各サービスのアップデート情報、
130:14 まあこれらをここで時系列で提供しておるということになります。 そしてAzureのまあユーチューブのチャンネルですね。まあデモ動画であったり、
130:23 技術解説、イベントセッションなどいろいろあります。まあ場合によってはですね、 あのドキュメントだと少し。。
130:31 文字がたくさんあって長いなという場合は、まあ動画でチェックするということも有効です。 これらも見ておくとよいかなと思います。で、活用方法として、
130:40 まあここに挙げておりますが、まあ定期的にチェックして、まあ新機能であるとか、 変更点を把握するとか、まあそういったことが挙げられておりますが、これはですね、
130:51 第一章のところで、まあ少しだけ取り上げましたけれども、場合によってはですね、 ある時点でクラウド移行。
130:59 提案したんだけども、やっぱりオンプレの方がいいよと。 オンプレの方がコストメリット高いよというふうになったんですけれども、
131:07 ただ新しいサービスが出てきた、あるいは新しく日本にサービスが展開された、 そういうタイミングで、まあ、
131:14 すごくあのお客様の要件にバチッと合うものが出てくることがありますんで。まあ、 そういった場合に、他のところに負けずに、素早く、
131:23 すかさず提案ができるようにするために。
131:25 まあ、こういったところで、まあ最新の情報当たると良いかなと思います。ですので、 まあぜひこういった。ウェブサイトですね、定期的にチェックしていただいて、
131:38 適時に素早く迅速に提案できる体制整えておくと良いんじゃないかなと思います。 それではですね、本節のまとめです。まあ、
131:48 本節ではAzureに関する情報の収集方法を学んできました。
131:55 まあ特にまあ、公式の情報収集源についてですね、これを取り上げております。 まあ特にですね、まあ、
132:01 お客さんの中にはオンプレイの方がコストコいよいよと判断するであるんですけれども。 ただ、先ほども先ほどの繰り返しになりますが、まあ、新製品登場、日本新規展開、
132:11 これもチャンスです。いつか訪れることがあるかなと思いますんで、こういった形で 継続的に情報収集して、提案の機会見逃さないようにしましょう。
132:25 では、本書のまとめです。本書。こういったものを見てまいりました。 キャフト和風ですね。移行の幻覚を専念させるためのフレームワークでした。
132:35 これらの概念構成要素、思い出せるでしょうか。まあ、 あの和風ウェブアーティテクテンフレームこちらについてはですね、
132:44 たくさん項目あるので、なかなかあの全部を覚えるというのは大変かもしれませんが、 五つのカテゴリー押さえておくといいんじゃないかなと思います。
132:55 そしてAzureマイブレットですね。まあ移行のツールですが、まあ移行そのもの以外、 まあインベントリング検出とか、
133:03 そういったところから使えるようなものであるというのを確認してきました。そして、 オンプレとAzureの連携例についてですね、
133:12 こちらファイルサーバーの拡張ですとか、三つの主要な事例を取り上げてきました。 そして、アダプティブクラウドアプローチですね。
133:21 まあ、 オンプレとかにあるリソースこれをAzureの管理統制下に置く方法を確認しました。
133:27 まあ特にですね、えっと、Azureの移行、 これはもちろんテーマではあるんですけれども、
133:32 絶対にAzureに移行しなきゃダメですと。 もうAzureがいいからAzureに移行を絶対にしてくださいと。
133:39 そういう提案をしていると、かえってあの不審がられるということもありますんで、 こういうアプローチも実際には定義されているし、そのオンプレを残す。と。
133:48 いう運用でも適切に適確に クラウド運用できるようになっているんですっていうのを説明する、その準備が できるかという点を確認していただければと思います。そして最後に情報収集ですね、
134:00 こちらの方法も確認してまいりました。アジルの最新情報であるとか、 あるいはコンプライアンス要件ですね。規制に関する要件、
134:08 どういうふうにクリアしているかというのを、 まあサービストラストポーダーとかで入手できるということをご説明してまいりましたこれらのこういった。情。報収集の方法 確認できたでしょうか。まあ、これら見てまいりました。それではですね、 午前中の講座。クラウドインフラですね。
134:29 ワイクラウドワイナシールの講座は以上となります。まあ、 インフラインフラストラクチャークラウドへの移行に関する講座以上となりますが、
134:41 この後、お昼休憩を挟みまして、クラウドセキュリティに。
134:46 関する講座が午後に続いてまいります。まあ、午後もまた、 私がセキュリティの講座を私が担当いたしますが、午後はですね、
134:56 少し結構駆け足になってまいります。最初はあの導入のショーはあるんですけれども、 それ以降は
135:02 結構矢継ぎ早にこういう製品があるんですよっていうのを紹介していくというスタイルで、進んでいきますので、結構ちょっと息切れがするかもしれません。
135:14 ただですね、セキュリティの章では、私の方で、まあ、 いろいろイラストをですね、工夫してスライドの方を挿入してますので、
135:21 もしあのちょっと息切れしそうだという場合は、 そのイラストに関する説明はゴーの章は行っていきますんで、
135:28 そのイラストがつまり何を意味してるんだっていうのをまず理解する。 そこをまず集中していただくと、
135:34 スムーズに午後の章も受けていただけるんではないかなと思います。
135:40 はい、それではですね、時間になりましたので再開させていただきます。 講師は引き続きスキルアップネクスト入江が担当いたします。
135:51 どうぞ方もよろしくお願いいたします。 それではクラウドセキュリティ信頼される提案のための必須要素の講座、
136:00 始めていこうと思います。本講座ではですね、まあ一章は導入という形で、 セキュリティ対策の必要性について確認をしていきます。
136:11 二章以降はですね、まあ基本的には 関連するAzureサービスの説明ということになっています。まあ、
136:17 これらを知っている方はですね、まあ気軽に聞いていただきたいんですけれども、まあ、 これから勉強していくという方はですね、まあ、
136:24 次々にいろいろなものを取り上げて行います。少しあの負担があるかもしれません。 ですので、まあ、各章各説で、製品コンセプトアナロジー、
136:33 たとえ話となるイラストを掲載しているので、まずはその部分の理解に注力してい。た。だ。 ければと思います。
136:40 本望図の範囲についてなんですが、まあ、ここではえ、 ミストサイバーセキュリティフレームワークにおけるえ記述を用意しておりますけれども、
136:51 防御検知対応に関する製品サービスを取り扱っていきます。ではですね、 もう早速なんですが、もう第一章から学んでいきましょう。
137:01 第一章セキュリティがなぜ必要か本書の概要です。 セキュリティはコストではなく投資だということを理解していきます。
137:10 そして次に、共有責任モデルを使いまして、 顧客のあのお客様の責任範囲の違いというものを理解していきます。そして、3つ目。
137:18 ランディングゾーンですね。活用方法を理解しますそうです。次に、 顧客は持つ懸念、そして払拭前の流れを理解していきます。この構成で見ていきます。
137:27 あ、それからですね。先ほど触れておりませんでしたが、今回、 第四章のところまでで、一旦区切りで休憩を入れようと思います。はい、
137:35 その点をご理解ください。
137:39 ではですね、早速ですが、DXとセキュリティの必要性について 見ていきましょう。セキュリティはですね、えっと、多くの場合、
137:47 まあコストというふうに捉えられがちなんですね。まあ、 それ自体はもう別に間違いではないんですけれども、ただですね、
137:54 この左側の人が言うように、セキュリティそれ自体がまあ、 直接的な利益を生むというわけではないんですね。ただ、まあ、
138:01 セキュリティのインシデントはですね、起きるかどうかじゃないんです。 これは必ずどのような。組。織も起こります
138:07 なので、ま、あいつ起こるかの問題であって、例外はないです。で、 確実に発生するということは、その規模を最小化することで、
138:15 まあ実際には被害額抑制分の効果が得られるというふうに考えます。 この点でセキュリティは投資なんじゃないかという考えをしているわけなんですね。
138:24 ではですね、初めにクラウドの役割について、 まあこちらも午前の講座で扱いましたので、もう軽く見ておきます。まあ、
138:31 オンプレの課題、これはもう午前中に見てきたものですね。
138:35 そしてクラウドの活用というのは、まあ、それらを解消して、 オンプレの課題を解消してプラスして、まあビジネスの俊敏性向上であるとか、
138:44 それを目指すものでありました。で、 ここからセキュリティの話題に特化した内容を触れていきます。まずですね、
138:51 サイバー攻撃の増加傾向が見られるということ。これはもう無視できない事実になってます。 初めにですね、ああ、この右側のグラフを確認していきましょう。
139:01 サイバー犯罪の検挙減数これも増加維持傾向が続いています。
139:06 で、左側の表なんですが、これはIPAの組織向けの重大脅威という表ですね。 抜粋したものですが、まあ、あのランサムウェア攻撃、
139:15 ランサム攻撃みたいな定番の攻撃がもうずっと順位を維持してるんですね。 まあ去年もありましたけれども、まあ、あの名だたる大企業ですね。
139:23 もうこれら攻撃によってもう被害を受け続けているんですね。 これはもう他人事ではないんです。そしてインシテント事例、
139:31 これをもう一つだけ紹介しておきます。
139:34 あるスタートアップが運営するアプリで、クラウドの設定ミスがありました。 その結果ですね。もう300万人とすごい数字ですけども、これ、
139:43 個人情報が外部から参照可能な状態となっていたみたいなんですね。 流出が確認されていないという調査結果だったんですけれども、
139:52 この企業はまあ事業の停止とか訴訟にまあ発展してしまいました。結構であの成長厳しくて、 もう前途洋々と言われていた。
139:59 華々しいスタートアップだったんですけれどもこの一件のインシデントにダメになっちゃったということなんですねもうたった1°のインシデントでまあ事業や企業沈むことすらあるということなんですねなんでコストだからということで対策をせずに済ませているという場合ではないということですでコストではなく投資ですよという観点で情報を一旦ここでまとめておきましょうまずはリスク低減ですねインシデントで発生する経営リスク低減しておきましょうということです
140:29 そして信頼の獲得ですねセキュリティが万全であるということはもう信頼の基礎になっていますでこれはですねあのインシデントを起こさないということじゃないんですよねたとえインシデントが起きたとしてもそれを的確にまあ迅速に裁けましたというんであればかえって新段階が待つということもありますでそしてイノベーション促進まあセキュリティ面が万全であるという一種の後ろ盾があればですね新しいことに安心して取り組めるということが考えられます
140:59 例えばですねあの組織マネジメントにおいて心理的安全性なんていう言葉ありますけれどもまあそのITバンドでもですね言うべきような言葉効果これは期待できるんですねというわけで本節のまとめですDXの重要な柱としてセキュリティを捉えようという考え方を紹介しました続いてもいきますクラウド共有責任モデルいきましょう共有責任モデルについて
141:26 まあクラウドに移行したからといってインフラ管理から完全に開放されるとは限りませんサービスの利用形態によってまあお客さん側も引き続き責任を負うということがありますこの内容を簡単にですがおさらいしておきましょう共有責任持ってるまあまずはオンプレとクラウドで比較するとどうなるかなんですがまあ大まかに言えばですねオンプレはもう全部すべてを管理するということになります全部管理クラウドサービスについてはまあその内の一部だけ管理するということですねまずこのイメージを持っておきましょう
141:57 その上でクラウドサービスまあイヤースパースサースまあ三つ種類ここで上げておりますけれどもまあそれぞれで責任範囲が変わっていますイヤースはまあ物理インフラ以外はもう自分で管理でパースについてはまあ価値創出の源泉であるアプリケーションこれはもう自分で管理するただしそれより下のレイヤーはクラウドマカディということになります
142:20 でサースについてはですねまあアプリもクラウド版に任せますということですねまあメールとか文書作成とか汎用的なサービス利用についてはまあこのケースですねでどういったサービス形態においても共通で顧客責任となる部分がありますそれがまあここに挙げたアイディーとアクセス管理でデータそしてエンドポイントですねまあデータであればまあ何が本当に大事か決めるのはユーザー席お客様席でエンドポイントまあ
142:48 ユーザーが使用するピーシーとかですねこのセキュリティ確保は顧客とのセキュリティIDとアクセス管理まあ誰が何をしていいか決めるのは顧客責任ということになりますこれらがいかなる場合でも保護するということを考えないといけませんこの共有責任モデルの理解はですねクラウドを使い始める場合にも重要になってきますまあまずはまあ期待値調整とか誤解の抑止ですねこれはクラウド側でやってくれると思ったのにという誤解をまず解きましょう
143:17 その上で責任範囲を明確化してまあ顧客はこの部分にお客様この部分に対応していなければいけませんよというのを理解してもらいますで責任範囲がはっきりしていたらあここは自分たちがチェックすればいいのかなと自分たちのとるべき行動が明らかになりますんで対応漏れが防げますでコア業務への集中これはもう自分たちがすべきことが明らかだったんであればすべきことしなくてよいこと区別できますんでまあリソースを適切に配分できますよねということです
143:47 でここまでの内容をまとめますクラウドは共同責任ですすべてをクラウドサービスの提供者責任とすることはできませんで責任範囲可変構造ですイアースとかパースとかサービス提供形式によって変わりますでこれが踏まえてまあサービスごとに顧客の責任範囲を常に確認しましょうということですねそしてデータとアイディーユーザー責任です誰が何にアクセスできるかこれらをどういったルールで制御するかっていうのは
144:17 お客さんの責任ですねお客様側であらかじめポリシーを用意しておくことが望ましいですもうさらっといきますが本節のまとめですサービス提供者とお客様で責任範囲の線引きをしましょうもうささっといきますがAzureランディングゾーンによる基盤確率これも見ていきますまあランディングゾーンについては午前中ちょっと見てきましたね実はベストプラクシスなんだということでした
144:47 まあこちらですねあります通りMicrosoftのベストプラクティスを反映したまあ実装であるということでしたランディングゾーンそして八つのデザインエリアについても午前中に少しだけ触れました今回もここではスキップさせていただきますそしてここからですね少し午前中に扱っていないコンセプトを取り扱っていきます左側プラットフォームランディングゾーンとアプリケーションランディングゾーンですね
145:12 プラットフォームランディングゾーンこれはあの組織内のシステム全体に関わるサービスを集約したものですでアプリケーションランディングゾーンこれは名前の通りなんですけれどもまあ個別のアプリケーションに関わるサービスこれをまとめたものですねでそのそれぞれがプラットフォームランディングゾーンと接続されていますで改めてプラットフォームランディングゾーンについて見ておくとですねこれは環境全体で共有される基盤サービスです 右側の図で言えばですねアプリケーションランディングゾーンよりもこの左側の部分これがプラットフォームランディングゾーンですまあIDやネットワーク接続とかあるいはまあセキュリティ設定に関わるポリシーまあこういったところも定義されていくということになりますそしてアプリケーションランディングゾーンについてなんですがこれはまああの個別のアプリケーションであるとかあるいはワークロードをデプロイして実行する環境になりますまあアプリケーションのサービス でそれを扱うデータとかまあそういったものはここに入ってきていますまあセキュリティに関することで言えばですねまあ例としてプラットフォームランディングゾーンが定義したまあルールとかポリシーですねルールとかポリシーというものがアプリケーションランディングゾーン内のリソースに適用されるということになっていきますこれらは各章で見ていきますでこの二種類のランディングゾーン内まあサービス連携はどのように行われ行われるかなんですけれどもここではもうあのハブアンドスポークの
146:38 構成を見思い出していただければなと思いますまあこの図の例ではですねアプリケーションサブスクリプションからコネクティビティサブスクリプションハーブに当たるものですねこれを経由してまあIDに関するリソースを参照しに行っているということが言えますまあこういった形で連携をしておるということですねそしてこのランディングゾーンの設計を踏襲するということはセキュリティ上どういうメリットがあるか
147:05 まあこれ整理しているんですけれどもまあここでは二つだけ取り上げます一つがサブスクリプションの民主化ですねアプリケーションランディングゾーン中はまあ原則として自由に設計開発が可能ですなのでまあ明らかに危ない設計っていうのはもうポリシーもうデプロイされてますんでそれでポリシーがデプロイドブロックス危ない設計はデプロイドブロックするためまあその範囲内でまあもうのびのびできるということですねルール内であればもう自由にできる
147:33 でこの点がですねまあ心理的にも割と開発を促進させやすいという側面がありますそしてもう一つがアプリ中心のアプロージですねまあオンプレートクラウドの比較でも話したんですけれどもインフラの制約内でものを考えるんじゃなくてアプリに必要なものが何かという観点で物事を進められますなのでまあアプリの機能要件としてセキュリティ要件あるんですけれどもそのアプリの機能要件と同じで
148:01 機能であるセキュリティ要件についても必要なものを組み込めるということになりますそしてランディングゾーンの活動についてはですねまあ顧客責任の遂行支援これでも役に立っていきますこれも一部だけピックアップしておきましょうまず大きいのはですね共有責任モデルの実装指針を提供するという側面です共有責任モデルにおいて顧客は何をすべきか
148:26 定義されてランディングゾーンにそれをどう実装するべきかまあ定義されていると考えられますそしてまあ顧客の果たす責任のうちまあセキュリティという面ではですねまあどのように実装すべきかというプラクティスこれをまあ示しているということになりますでは簡単ですが本日のまとめですランディングゾーンによってまあ実装のベストプラクティス提供しており提供されていますので確認して活用しましょう
148:55 そしてセキュリティの価値提案について顧客が持つ懸念を懸念しそれを懸念を確認してそれを払拭するという流れを意識しますまずセキュリティ上の懸念ですねまあこのデータ漏洩コンプライアンス違反不正アクセスまあこのあたりはもうイメージできるかなと思いますで移行中のセキュリティ確保についてなんですがこれはまあインフラに大きな変更があるタイミングこれは緩みが生じやすいので注意しましょうということですねそしてインシデント対応チェーン
149:25 インシデント対応は遅れるともう被害が拡大してしまって取り返しがつかなくなるということもありますさて過剰な対策コストまあセキュリティは万全にしておくべきではあるんですけれどもただもう際限なくお金をかけるということもできてしまう分野なんですねなので必要十分っていうのを意識するということが必要になってきますそして構成設定管理ミスまあ冒頭でも触れましたまあインシデン通りがまさにこれに該当しますねまあ一番よく発生する事例がこれです
149:54 そしてこれら顧客の懸念とお客様の懸念とそれら払拭することによるビジネス価値への転換まあこれはですねあのここで記載しているものは別にすべてではないですしまあすべてを取り上げていきませんけれどもまあ簡単にいくつか紹介しておきましょうまあここではまあ不正アクセスについて見ておきましょうかねエントラIDによるID基盤で不正アクセスを防止しましょうとそしてセンチネルMicrosoftセンチネルによって仮にインシデントが起きたとしても素早**れを補足して
150:23 事業が止まらないようにするということですねあくまで例ですけれどもまあこういった形で顧客が持つお客様が持つ懸念とかシステム要件とかそういったものに合わせて対応で使えるソリューション関連付けていくとよいかなと思いますそしてセキュリティのソリューションの価値に関する調査結果これは資料に掲載しているんですけどもここではスキップさせてくださいではここまでのまとめですねパートナー提案時の要点として紹介していきます
150:53 まずはお客様の懸念点を確認しましょうそして責任範囲を明確化共有責任モデルも使いつつお客様の責任範囲明確にした上でこれから取り組むべきことを確認していきますそれからとそれらの取り組みに関連するセキュリティ技術とかAzureの製品とかこういったものを説明をしていきますそして続いてAzure landing
151:14 zoneこれをどういうふうに活用していけるか説明をしていきますまあ実装のベストプラクティスの確認ですね
151:22 そしてまあビジネス価値について理解をしてもらうということになりますで簡単ですが本節のまとめこれはもう先ほどお話なんですがまあ顧客の懸念確認から価値の認識共有これまでの流れを認識していきましょう広く本章のまとめなんですがこの章ではもうこの四つのトピックを導入として取り扱ってきました
151:46 これら総合してセキュリティは投資なんですよねという方針でまあ提案と話を進めていければベストですそして第二条エントラIDについてまあ早速進んでいきますで概要はですねこちらのページで見ておきましょう0トラストの概要とエントラIDそしてアールバックの基本そしてIDの種類でエントラIDで実施できる基本的なリスク検知とブロックの仕組み
152:16 これらを見ていきますそれからですねえっと冒頭で触れた通りこれ以降はですねあの主にAzureサービスの内容の紹介でもずっと続いていきますこれでこれ以降説の最初のイラストで概ね言いたいことをまあ例え話とかも含めて描写するようにしておりますですのでちょっとついていくのが大変かなというふうに思い始めた場合はですねこのまずはこのイラストの部分の理解だけ注力してくださいそれではいきましょうエントラIDの概要について
152:45 では見ていきましょうここではですね0トラストとエントラIDの関わり見ていきますでこのイラストではですねこの左側の人物オフィス内ではもうちょっとセキュリティ緩くても大丈夫なんじゃないですかとまあ厳しいセキュリティに疑問を持っている様子ですねでしっかり入館ゲートとかあるオフィスだったらまあこう思うことあるかもしれないですただですね実際にはオフィス内にはもう会社に属する人間だけが立ち入っているとは限らないですよね
153:12 なんでまあゲスト入管証を持って会社の敷地内に入り込んでで立ち入りが許されていない区域に侵入するっていうことは起こりえますなのでまあいかなる場所でもカードキーとかざしてですねその人がエリアに立ち入り可能かチェックするという必要があるんですねこれが0トラストの一番基本的な考え方を表現していますでこれを元にして次このページで内容を見ていきますで0トラストの基本コンセプトなんですがこれは見ていきますネバートラストalwaysベリファイ
153:41 これはまあ先ほどの例で言えばまあいかなる場所でもカードキーかざしてもらうということに他なります常に検証をしましょうということですねで三つの原則明示的な検証最小権限アクセスそして侵害を想定するということですね上の二つはまあわかりやすいかなと思います侵害を想定するについてなんですがこれはあの侵害必ず起こりうるんですよねなのでそこから復旧することをいかに迅速に行えるかというのを問うています
154:11 これはですねまあセキュリティの文脈ではレジリエンスっていうキーワードでよく語られていますこれをキーワードにして調べていくといいかもしれませんでIDが中心的な役割これもまあ考えてみると当然の話ですねまああのまず目の前の人が誰かまあそれを明らかにしないとその人が何していいか特定できないんですよねなんでIDが中心になるということになりますこの0トラストとエントラIDの関わりこれを少しずつ見ていきます
154:40 でここではまあまあ一部だけまあ紹介しますがまあポリシー決定ポイント兼ポリシー執行ポイントですというのを書いていますまあこの点にまあ0トラストのコア機能要素が表れていると思いますえエントラIDをですねまあいわば受付みたいなものに例えるといいかなと思います受付でですねゲストが来たらああなたはこの会議室使えますねどうぞと案内できるとこれがまあポリシー決定にあたるそして実際にあちらのエレベーターをお使いください会議室に繋がってますと実際に案内する
155:10 あるいはまあその人があの会議室じゃなくていきなり社長をして乗り込もうとしたという場合あったとしたらそれを止めるで場合によってはですね受付にまあ身なりの怪しい人が来たらもうそのまま即座にお帰りいただくよう対応することもあるかもしれませんこれらがポリシー執行ですエントラIDはですねこの人が誰かこの人が誰かでどこに行ってもいいか判断するための場所でもあるしまあ実際案内していくためのない場所だということもありますこのページまあそのことを説明しているんですね
155:42 そしてランディングゾーンにおけるエントラIDの役割これもちょっとだけ見ておきますエントラIDはもうある意味でランディングゾーンのまあ中心にあるサービスと言ってもいいかもしれませんというところですねその認証をクリアしなかったらそもそもAzureに入っていけないんですよねなんである意味ではまああらゆる要素が影響下にあると言ってもいいかもしれません一方でですねエントラIDの関連サービスいくつかあります
156:07 一つがこれpimピムですねこれは後で見ていきますそしてもう一つプラットフォームランディングゾーンのIDサブスクリプションですねまあ絶対ではないんですけども例えばここでActive DirectoryはAzureでホストしたようなサービスまあエントラIDドメインサービスとかこういったものデプロイすることもありますサブスクリプションまあいずれにしてもIDとアクセス権に関する役割を総合的に担っておるということですねではまとめですまあエントラIDと0プラスの関係性見てきました
156:36 ではですねアールバックの基本これも続いて見ていきますこれも例によってイラストで確認しますこれも受付対応関連ですね一人一人名簿照合して通行証を渡すの大変だなと課題をまあ警備員さんが持ってるみたいですねまあ負担が大きいねだったら部署単位で権限というものをまとめて管理して部署共通の通行証を渡すっていう運用がまあより楽なんじゃないですかという提案がここでされていますまあこれがですねアールバック基本的な考え方になっています見ていきましょう
157:07 アールバックのコンセプトこれ基本はですねある役割が何に対して何をできるかというのを定義するんですね基本はこの要領で権限設定を行っていきますポイントになるのはもう基本的にユーザーではなくてロールに対して権限を設定していくということですねユーザーに対してもう一つ一つ権限を渡していたらもうパターンが多くなりすぎてしまってもうわけわからんということになってしまいます
157:35 でAzureを使用していく場合ですね二種類のrdhrバック運用することになりますエントラIDとAzureのアールバックの仕組みがありますエントラ側はID関連Azure側リソースに関する権限を管理しますでわざわざ二つに分けてるんですけどもこれ理由がちゃんとあるんですねで大まかにはこの下の図の方で見ていきましょう実際にアカウントの侵害が起きたとしますこれですねアカウント侵害済み
158:05 でエントラ管理者のアカウントは侵害されました仕組みが分離されていればですねそれだけではこの人はAzureのリソースにアクセスすることはできません一方でじゃあAzureの管理者は仮に侵害されたとしたらどうかとそのままではまあアクセスできてしまうんですけれどもエントラ管理者の方が生きてさえいればですねそのAzure管理者のアカウントを無効化できます無効化できるっていうことはAzureリソースへのアクセス抑止できるということなんですね被害を抑制できます
158:35 なのでまああの分離していることで被害侵害死の対応の知らせがすごくよく変わってくるんですね楽になるそしてこのIDに関連して特権IDこれもですね管理者アカウントなんですが最重要なものです一般にですね管理者アカウントこれはあの何でもできるアカウントですなので攻撃者はこの特権IDを必ず狙っていきますできるものなら
159:01 でもしこれが攻撃者の手に落ちてしまったらですね被害は甚大なものになってしまいますこの図ではまあ管理者アカウントを乗っ取るって発想を整えた攻撃者がいますそして金曜の夜を待って攻撃を仕掛けようとしていますなんで金曜の夜なんですかねはい金曜の夜ともなればですねもう担当者たちITだったり石油であったり担当者たちはもう飲みに行ってますで場合によってもうそのまま週末の休暇に入ってます
159:30 そうするとまあ攻撃のテラス整えてあるんで週末にゆっくりともう管理者アカウントを使ってですねもうじっくりと攻撃を進められるということになりますランサムウェアとかによる暗号化とかもですね時間ちょっとかかるんですけども週末の時間を使ってゆっくり進められるんですねで結果もう担当者ですね月曜に出社して憂鬱な週明けを迎えるということになってしまいますこうした事態をなんとかして防ぎたいというのがありますができます
159:58 こうしたことが起きないように特権IDを守るためのソリューションっていうのがあるんですねこれがエントラプリビレッジとアイデンティマネジメントですねジャストインタイムのアクセスそれから承認のワークフローまあこういったものがありましてなので必要な時に承認が下りた時だけ特権IDを使えるようにしましょうということができます
160:21 まあ、特権アイデアはほぼ何でもできるんですよね。なので、 最小権限っていうとちょっと違うかなという感じになるんですけども、代わりにまあ、
160:30 こういったソリューションを使うことで、有効期間を最小限、 最低限に抑えるということができます。そういう形で、
160:37 まあ最小限のルールを守ろうとしているということなんですね。では、 本節のまとめです。必要最小限にこだわりつつ、
160:44 効率的に権限管理していきましょうということでした。
160:49 ではもう早速次に行きます。AzureワークロードID IDはですね、 必ずしもユーザー、すなわち人間に対してだけ付与するものではないです。
160:59 誰が何をしてよいですかという権限を管理する際に、 この行動の主体が人以外ということもありえます。まあ、ロボットとかですね。
161:07 まあすなわち人以外のものにもIDを付与しなければいけません。 じゃあ付与しましょうということで、まあ、
161:14 ワークロードIDが存在するということになります。
161:18 まあ基本はですね、アプリやサービスとか、まあそういったユーザー以外のIDですね、 ユーザー以外のものも、まあAzureリソースにアクセスするという場合は、
161:27 ちゃんとIDを用意して懸念管理としていかなければいけません。ちょっとまあ、 ちょっとだけ補足なんですが、まあ、先月のMicrosoftのイベントで、
161:36 まあエントラエージェントIDというものも発表されております。ここでは それについては一旦考慮から発送しております。あらかじめご承知おき。くだ。さ。いはい
161:50 え、このワークロードIDについてなんですが、え、いくつか種類があります。 まずサービスプリンシパルですね。これが一番基本的なものです。まあ、
161:59 アプリの実態を指すIDでまあアクセス権の付与対象になってきます。まあ、 サースとかAzure外のアプリもこのIDで識別することで管理下に置くことができます。
162:09 え、一方でマネージドIDですね。 マネージドIDはこのサービスプリンシパルをAzureリソースように、
162:16 まあ抽象化したものというふうにされています。
162:20 システム割り当てとまあ、ユーザー割り当てのマネージドID、 まあ2種類あるんですけれども、システム割り当ての方はですね、これは
162:28 AzureがもうID自体を作成してリソースに割り当てます。なので、まあ、 リソース作成したら、
162:34 その瞬間Azure側がもうIDごとポジッと割り当てをしてくれるということになります。なのでまあ、IDのライフサイクル管理、全部Azureに任せられるということなんですねえ。ついでにあの付随する資格情報ですね。これも。自動で管理ができます2、人で
162:50 でユーザー割り当てこれはID自体はユーザーが作成します。で、手動で割り当てる。 ただしあの視覚情報ですね。この管理はAzure側に行ってもらいます。まあ、
163:02 管理の手間が省けるという点で、まあ、あのシステムが割り当てたID、 そしてユーザー割り当てのIDでサービスプリンシパルという順で適用可否検討すると良いかなと思います。
163:17 これらIDの管理の基本についてですね。ここで、見ておきましょう。 ここではですね、IDとまあそれに付随するまあ、視覚情報のまあ2種類で見ていきます。
163:27 視覚情報はですね、まあ一旦ここではあのIDに対応するまあ、 パスワードみたいなものと理解しておくとよいかなと思います。
163:36 一旦はいサービスプリンシパルについてはですね、 視覚情報はキーボールドで管理するというふうに設計することが、
163:43 ブラックレスとしては良いとされています。
163:46 まあシンプルではあるんですけども、これがまあ基本のプラグです。で、 マネージドIDについてシステム割り当ての方は、まあIDがAzure側で作成されます。
163:56 IDもAzureが作成してくれます。で、視覚情報、 これもAzure側で管理をしてくれます。で、リソースが削除された場合、まあ、
164:05 IDが不要になった場合ですね。その場合、IDもついでに自動削除してくれます。 まあ楽ですね。
164:14 ユーザーバリアの方は、ユーザーがまずIDを用意します。え、それらをえ、 マネージドIDで管理するとなると、まあ、
164:22 視覚情報についてはAzure側で管理してくれます。で、一方でこちらはですね。。 IDを割り当てたリソース削除したとしても、ID自体は残ってしまうんですね。
164:34 なので、自分で削除をする必要があります。
164:38 このIDの削除漏れがあるとですね、そのID、不正利用される恐れがあるので、 ここは注意するようにしてください。では本節の窓です。
164:49 ワークロードIDの基本的な用途、それから種類を理解してきました。 次はエントラIDのリスク検知機構ですね。これを見ていきましょう。
165:01 で、このイラストではですね、うっかり会社に忘れ物をしてしまって、 夜間にオフィスを訪ねるという従業員の様子が描かれています。昼間はですね、
165:10 もう警備員の人も笑顔で挨拶してくれるんですけれども、まあ、 厳しい表情でIDの提示を求めています。え、こうなるのはですね、
165:18 本来人が訪れるはずのない時間に人が訪れたからなんですね。で、 異常を指した警備員としては守りを固める必要があります。
165:26 これと同様のコンセプトをエントラIDとかでもできるということ。に。なります
165:34 まずじゃあ条件付きアクセスについて。条件付きアクセスは、まあ、 何らかの条件が揃った時に、まあ対応するアクションを実行するというものですね。
165:43 例えばまあ、ユーザーがまあ社内からアクセスしていればアクセスを許可しますとか、 まあこういったルールですね。あるいはまあリスクが検知されればブロックをするとか、
165:54 こういったものを定義できるような仕組みです。
165:58 で、この条件付きアクセス、まあ、 ワークロードIDの方にも対応をしているということを書いております。
166:06 そしてもう一つ重要なコンセプトとしてエントラIDプロテクション、 これを取り上げていきます。これはですね、ユーザーサインインの、
166:15 まあ通常とは異なる振る舞いを検知するといったものスコアリングを行っているんですね。 まあ、冒頭のイラストで示したような普通とは違う状況があるとリスクとして認識します。
166:27 で、この図の例ではですね、 ユーザーaが組織のIPでいつものデバイスからアクセスしています。ただし、まあ、
166:35 普段とは異なるブラウザを使っているという状況ですが、 これはまあ特に大きな問題とはみなされないことが多いかと思いますね。
166:43 リスクは低いと算出されている一方で、ユーザーaかなと思しきものが、これが基地の競技、 IPも危ないですね。そしてそれが
166:52 普段と異なるデバイスから異なるブラウザでアクセスをしてきている。
166:57 これはもうハイリスクというふうに判断されます。そしてですね、 これいずれもこの段階ではですね、リスクの評価だけを行っています。
167:06 スコアリングだけを行っている点に注意してください。で、まあああ、 検出できるリスクの例、色々あるんですけれども、ここは一旦ここではスキップします。
167:17 そしてこの検知されたリスク。これはですね、 条件付きアクセスと組み合わさることで効果を発揮します。
167:25 リスクを検出した時に何らかのアクションを取り、 まあこの場合はまあブロックするとかですねということができます。なんでまあ、
167:33 リスクは高いというサインが行われました。それがまあ、記録されると、 条件付きアクセスでこれはもうブロックしましょうというふうに判断して、
167:42 アクションを取るように設定ができる。こうすることで、まあ、 例えばID関連の脅威については、
167:48 もうエントラIDの枠組みだけで基本的に対応だったらできるということになります。
167:55 ではまとめです。エントラIDプロテクションと条件付きアクセス、 これをセットで使うと効果的だということをご紹介してきました。では、
168:06 本章のまとめです。本章ではIDの運用、それから各種基本的な考え方見てきました。 まずはですね、エントラIDの基本的なことをまず押さえておきましょう。で、
168:18 もうどんどんいきます。。第三章、 Azureでのセキュアなネットワーク構築について。
168:26 エム9時はこちらです。で、概要を見ておきましょう。 AzureバスチョンでAzure firewall、それからWebアプリケーション、
168:36 ファイアウォールそしてAzureディーロスプロテクション、これらを順に見ていきます。 では、Azureのバスチョンですね。例によってイラストで理解をしていきます。
168:47 左側これはバスチョンを使わないケースのアナロジーです。
168:52 泥棒さんがですね、そのターゲットである。まあ倉庫 侵入してしまったといういう例ですね。まあ駐車場ですかね。
168:58 まあ駐車場かどこかから倉庫まで、もう直通の経路があってですね。軽も経路、 非常にシンプルだというケースです。まあこう、
169:05 そもそもこういう便利な勝手口用意しておくこと自体がもう間違いですね。で、 現実でもですね、もうリモートワークしたいからって言って、
169:12 こうした勝手口を本当に勝手に用意してですね、インシデントにつながるんだということ。 が。も。う非常にたくさんあります
169:21 で、右側のイラストはですね、まあ守衛室を経由しなければ中に入れないというような、 もう頑丈な要塞がどうも築かれているということですね。まあ、攻撃者、
169:30 必ずあの下調べするんですけれども、 下調べの段階でもこういう風な道しかないなというのがわかったら諦めましょうねということになります。パスチョンは、この頑丈な入り口の守りでもって、リモート開発者を迎え入れられるようにするという体制を用意できます。
169:49 で、バスチョンを使う場合、使わない場合、それぞれ見ておきましょう。左側の図。 これはバスチョンを使わないケースです。で、
169:57 Azure内のプライベートネットワークに管理対象の仮想マシンがあります。 これをリモートから管理したいという場合、まあ、
170:05 パブリックリメインした踏み台となる仮想マシンをまた別で用意して、 それを踏み台としてターゲットにアクセスします。まあ、
170:12 踏み台がインターネットにさらされているんですよね。これ、リスクがあります。
170:18 で、右側はバスチョンを使うケースですねえ。ポータル経由でAzureバスチョン使って、 まあ仮想マシン起動しますプライベートはネットワークの中にえ、
170:28 仮想マシンを起動しますで、Azureポータル使ってるんですね。 起動にということは必然的にえ、エントラIDを経由することになるんですね。
170:37 利用するにあたっては、開発者は必ずエントラID経由してえ、 ポータルにアクセスということは？ということは、エントラIDの。
170:46 まあ関係ないですね。認証基盤を減ることになるというため、 安全性が保たれるということは言えます。で、
170:52 利点というスケース整理するとこういった感じになります。まあ、 まずはセキュリティ向上ですね。まあ、
170:58 インターネットに公開されるエンドポイント減ってきますんで、リスクが減ります。で、 運用負荷削減、パブリックにさらしたVMがあるとですね、
171:07 そのセキュリティ脆弱性の対応も永遠に行わなければいけないということになります。
171:12 で、対応漏れが生じると、もう重大なインシデントになってしまうということになります。 まあ、そうした対応への負荷がですね、バスチョンを利用していえば、
171:21 まあ理論的にはなくなるということになります。そしてまあ、柔軟な開発体制ですね。 バスチョンを使ったら安全なリモート開発が可能になります。まあ、
171:30 固定のIP持ってないリモート開発者もまあ参画できるようになるという利点もありますね。
171:38 でまあ、スケール比較プランの比較もしておきましょう。まあ、 基本はあの要件にもして選ぶというものではあるんですけれども。はい、見ていきます、
171:47 ディベロッパーこれはまあ、あの名前の通りですね。まあ、一番基本的なものです。まあ、 開発中とかに使うものであるこということですね。ベーシックになってくると、
171:56 これピアリングされたああ、仮想ネットワークに接続、 これはできるようになるということになります。これまあ、言ってみればですね、
172:03 ハブアンドスポ。ー。ク。の構成をとっ、ている時に
172:06 ハブに置いたバスチョンから、まあスポークの仮想ネットワークに入って、 まあ仮想マシン管理できるようになりますよということです。
172:15 そしてスタンダードになるとですね、まあファイルの転送とか、まあ何かより複雑な、 管理作業に対応しやすい機能というものが、いろいろ増えております。で、
172:26 プレミアムになってくるとですね。まあ、プライベートネットワーク経由まあ、 より強化なセキュリティ要件であったり記録まあ監査対応とかに。
172:35 対応するためのログ残すとか、まあ、こういったものに対応できるようになりますまあ、 評価のセキュリティ要件のガバナンス要件に対応できるというものですね。はい、
172:45 というわけで、まとめです。バッジョン活用して、 まあ安全に仮想マシンにアクセス管理できるようにしましょう。はい、では
172:53 次はもうどんどんいきます。ファイアウォールAzureファイアウォールですが、 これは割とファイアウォールとは何かっていうようなコンセプト自体はシン。プル。
173:04 あらかじめ決まった人、 あすなわち決まった通信しか通しませんアポがない人は入っちゃダメですというものですね。
173:12 まあ、こういったルールを定義して運用するためのものです。 このAzureファイアウォールについてはですね、まあ、
173:19 クラウドベースのマネージトなファイアウォールというのがシンプルな表現かと思います。まあ、主にあの仮想ネットワークの境界に配置しまして、通信をチェックします。あ、まさに門番みたいな。
173:32 立ち回りをしてくれるやつなんですね。 なんである通信がまあ意図された場所にのみ向かうように、
173:39 まあ目を光らせてくれるんだよというものです。で、主な特徴はですね、 まあやはりあのクラウドサービスであるということが言えるかなと思います。
173:48 まあクラウドであるので、 まあ自動スケーリングとか適用できる柔軟性があるということですね。そしてまあ、
173:56 高度なトラフィック成長として項目挙げておりますが、まあ。
174:00 ここに記載した内容は、まあだいたいオンプレイの機器でも、 まあある程度対応できる機能かなと思いますが、まあ、あのセキュリティ面で、
174:08 通常必要とされるような要件、これはもう一通り満たせるぞということにはなっております。 そして高度な管理機能、まあ、
174:15 ファイアウォールマネージャーというものがありまして、まあ管理。 効率的にできるようになっていますし、あとまあ、脅威インテリジェンス系の機能とか、
174:23 まあAzure serviceですね、 Azure serviceと連携できるということ。もポイントになってきます
174:35 で、ランディングゾーンにおける役割、これはもう 何回も見て聞けるかもしれませんが、
174:40 ハブアンドスポーク構成における中心的なセキュリティコンポーネントです。とまあ、 こういったハブアンドスポークの構成が取られているという時に、もうハブの部分ですね。
174:51 コネクティビティ、サブスクリプション、こちらにファイアウォールが配置されます。まあ、 あらゆる通信がですね、そこを通るので、まあそこに配置することで、
175:00 まあ一元的に通信を制御できるということ。になり。ます
175:06 ファイアウォールのスケジュールプランの比較しておきますが、 これを見ておきましょう。ベーシック。まあ、
175:14 ベーシックはもうそんなの通りもう基本的なものですね。 もう対応するネットワークのトラフィック量、ちょっと少ないかなというところなんで、
175:23 まあほぼほぼ開発用かなと思います。で、スタンダードが。まあ、 これがまあビジネスユースでは一番一般的な標準のプランかなと思います。
175:33 そしてプレミアムですね。このプレミアムがまあ、 より大規模なトラフィックをサポートするとか、あるいはまあidpsですね。
175:42 こういったものを使って侵入検知するとか。あ、侵入検知と対応も含みますね。 侵入検知と対応とか、
175:49 そういった共有保護の機能を使うべきだという場合に使用をすることになります。
175:59 で、あと補足としてですね、ファイアウォールのルールタイプというものがありまして、 まあこれは3種類あって、まあ評価される順番とかも決まっているんですけれども、
176:10 詳細はちょっとこの時間ではすいません、スキップさせてください。では本節のまとめです。 ファイアウォールをうまく使って、不要な通信とか、
176:19 もう遮断するようにしましょうということです。では次に行きましょう。 ウェブアプリケーションファイアウォール。
176:28 このウェブアプリケーション、ファイアウォールまあ、 これもう和風っていうふうに訳しますけれども、
176:34 ファイアウォールというふうについているんですけれども、これは ウェブアプリケーションに対する通信に特化しています。で、
176:42 この手荷物検査のイラストのようにですね、 危ないものがないかというのを内容まで見るというのが特徴です。
176:51 この和風の概要なんですが、 これはウェブアプリを標的にしたサイバー攻撃から保護をするというようなものです。まあ、実際に通信内容をチェックして、まあ攻撃用のペイロードかなと思われるものがあったら、それを検知してブロックするということをしてくれます。ただですね、これ重要な注意点がありまして。えっと、この和風にはですね。まあどうしてもまあ、護検知とか細く漏れとか。
177:20 これはもう必ず生じます。なのでまあ、正しいアプリロジックの実装が一番重要ですね。 なんでこれ、セキュリティをワフ任せにしてはいけません。
177:28 こういったエスキューエルインジェクションのクロスライトスクリプティングとか、 まあ通信チェックして、これをできる限り防ぐようにはするんですけれども、
177:36 だったらアプリはもう適当でわという態度をとっていいかって言ったらダメです。 ちゃんと誤検知で補足漏れがあるという前提で、もうアプリを作ると。
177:44 ころからちゃんとしておきましょう
177:48 でAzureにおける和風提供形態あ、提供形態主に二つあります。 アプリケーションゲートウェイ上の和風と。フロントドア上の和風ですね。まあ、
177:58 主な違いは保護対象がリージョンレベルかグローバルレベルか、ですね。 アプリケーションゲートウェイの方がリージョンレベルで、
178:05 まあこちらがあの比較的オーソドックスでシンプルな用途です。まあ、ゲートウェイが ウェブアプリケーションに通信をルーティングしますと、今前の段階で。
178:16 まあ、通信なりのチェックをかけるということになります。 フロントドアはこれはCDN、
178:22 まあコンテンツデリバリーネットワークのサービスでして、 まあウェブコンテンツとかを効率的に、
178:28 まあ世界各地の閲覧者に配信できるようにするためのサービスです。で、この時ですね、 世界中の利用者から近いエッジからも配信をコンテンツ配信をするというのが、
178:38 まあ基本機能ではあるんですけれども、このエッジの部分からですね、 利用者から悪意あるリクエストがある。か
178:45 これをチェックするっていう機能も加え、加えられるんですね。そうすると、 まあ自ずとまあグローバルレベルで、まあ統一化されたルール適用して、
178:55 ブロックするということができるようになります。で、この枠の比較ですね。 まあ基本はあのリージョン単位と、まあグローバル単位の保護、まあ、
179:04 根本的な違いがまずあるんですけれども、まあそれ以外ではですね、 フロントドアのまあスタンダードとあのプレミアム上位プランですねがあると。
179:14 この上位プランであるとまあ、特にあの脅威インテリジェンス系の機能とか、まあ、 より高度化された運用ができるんですね。なんでまあ、
179:22 グローバルに提供するサービスを運用するかどうか、あるいはまあ、 それからどれほど高度な機能を和風に求めるかで使い分けるといいかなと思います。
179:31 というわけで、本節のまとめです。 追加のセキュリティレイヤーとして和風を活用しましょう、
179:37 和風任せはやめましょうということですね。
179:41 では、Azureディードスプロテクションについて、これも見ていきましょう。 まずディードス攻撃なんですか？という話なんですが、このディードス攻撃、これはですね、
179:51 左側のイラストで示したように、まあ、 あの敵の大群がどうも押し寄せてきているなという状況です。これこうやって、
179:58 まあ物量でこちらを圧倒しようとしてくることですね、この度数、 まあディナイアルオブサービスの略なんですけれども、これはまあ、
180:06 サービスを停止させようとするという攻撃を指。しています
180:09 なんでまあ、トラフィック量を増加させてですね、それをサーバーがさばけなくすることで、 サービスを停止させるというようなものです。で、
180:17 こうした大群が押し寄せてきた場合ですね。それをそのまま何もせず迎え入れてしまうと、 本丸がやられちゃいますね。お城の本丸がそうすると、もう、
180:25 つまりはサーバーがダウンしてしまうということになってしまいます。 そうするとちょっと問題ですので、
180:31 まずはもうとりあえず一旦頑丈なもんを用意してやってですね、それ。ら。を。 大群をせき止めないといけません
180:37 そのために使えるサービスとかが、ああ、サービスがまあリードスプロテクションですね。 このリードスプロテクションの概要プランと一緒に、
180:46 まあ概要図でチェックしておきましょう。まず攻撃者ですね、 これはボットネットに指示を出します。このボットネットっていうのは、
180:54 まあ脆弱なアイオーディー機器とか、 まあハッカーに乗っ取られた大量のデバイス分ですね
181:00 それらがまあ大量のトラフィックをまずAzureとか、あるいはまあ、その中。の。
181:06 テナントのリソースに送信をしていきます。で、 ここからプランごとのカバー内容を見ていくんですが、
181:12 まずインフラストラクチャープロテクションインフラストラクチャープロテクション、 これはAzureが自分自身を守るためのものですね。
181:21 なんでお客様の方で特に何も設定する必要はないです。まあ、 勝手に守られてくるとただですね。これを持って、
181:28 まあ自分たちの環境も完全に守られているなあと考えてはいけないんですね。
181:34 で、Azure全体で、例えば毎秒十万アクセス受けてますというぐらいだったら、 まあそれほどトラフィック量多いとは言えないんじゃないかなと思うんですけれども、
181:44 一方でまあ自社の位置ネットワークに対して毎秒十万アクセス受けてますとなったら、 それはちょっとビードス攻撃かなというの可能性考えた方がいいかもしれません。その場合、
181:54 まあインフラストラクチャープロテクションでは、 まあ対応されないというふうに考えられます。んで、こうネットワー。ク。プロテクション
182:03 かを自ら導入するということになります。なので、一企業のテナントとしてで できる対策として、まあ、
182:10 ネットワークプロテクションとアイピープロテクション使えるようになっております。 ネットワークはですね、まあ、仮想ネットワーク単位、
182:19 そしてアイピープロテクションがですね。1I、ピー。まあ、すなわちまあ、 一つのアプリ単位で保護することができます。
182:30 プランの比較なんですけれども、まあ主な違いはですね、 マイページのイラストで見た通りです。なんでここでは。まあ、
182:37 コスト保護についてちょっとだけ補足をしておきましょう。まあ、ディードス攻撃、 これ別の側面としてですね、リソースを枯渇させるんじゃなくて、
182:46 リソースが枯渇しないようにオートスケールで対応させて、 まあそのコスト増加によって経済損失を与えるという考え方をするケースというものが
182:54 あります。
182:56 で、その場合、コスト保護っていうのは、まあこの損失をまあ補填することができるので、 まあある面では保険みたいな形で聞くようなものと捉えられるかなと思います。
183:06 これはネットワーク保護プランについてのみ有効です。仮想ネットワーク単位ですね。では、 本節のまとめです。リードスプロテクションについて、確認をしました。
183:18 パブリックにするサービスがあったら、可用性を意識して対策を行っていきましょう。では、 本書のまとめです。
183:25 まあ、これが四つのプロダクトを見てきました。まあ、それぞれのですね。 使用場面を意識しておいてください。
183:36 では四章ですね。この章終わりましたら一旦休憩に入ります。 機密データの暗号化と保護について目次はこちらです。
183:48 概要をここで確認しておきましょう。 Azure Key Vaultの基本ユースケースそして厳格なコンプライアンスの件がある場合のソリューション処理中データの保護まあ、主にこれらを見ていきます。
184:01 です。まあ最後にですね、まあ、比較表みたいなものを用意しておりますが、 これはもう参考程度止めておきます。では見ていきましょう。
184:10 AzureKey Vaultについてでは、Key Vaultの概要から見ていきます。 鍵はですね、まず一般にとても大事なものです。そしてよく使うものでもあります。
184:22 で、左側の人はですね、あまあこれよく使うものだしって言うんで、 わかりやすい場所で管理しようとしてます。今でも壁に鍵かけてるとこってあるんですかね、
184:32 わかんないですけどもしかしまあこれではですね、あの安全上の問題に発展してしまいます。 盗難の発生とかですね、もう容易に起きてしまうんですね。で、大事であるからこそ、
184:44 厳格に厳重に金庫とかで保管する必要がありますえ、ここではですね、 シークレット管理の重要性について見ておきましょう。
184:52 シークレット管理、ITシステム運用では極めて重要です。まあ、 理由は言うまでもないことなんですけれども、まあ、漏洩してしまったら、
185:00 自社のデータ資産度外者がアクセスできてしまうということになってしまう。まあ、 非常に重大なインシデントになってしまいますね。で、シークレットとは何か？これは
185:09 いくつか例を記載しておりますが、まあ、パスワードとか証明書とか、まあ、 いくつかございますえ、これらはですね、シークレット、まあ、
185:17 シンプルなテキストレーターとし。て。表現されることも中にはあります
185:21 そしてですね、便利だからって言って、 ソースコードに直接それらを記述してしまうこともあるんですね。
185:27 開発やっぱサボってしまってね、これがですね、 古くからもインシデンのパターンとして存在してます。え、さらにですね、
185:34 これ誤って行動リポジトリに情報を記録してしまうとですね、 もう消すことも難しくなってしまう。もう悪夢ですね、こういうこともある。え、
185:42 これ正しく管理するにはどうするかなんですけれども、三つの観点記述しております。
185:48 アクセス制御を行いましょうで暗号化して保管しましょう、 適切な感覚で更新しましょうと思うんですね。で、これを少し一般化して言いますと、まあ、
185:59 機密情報を守るために、まずは情報に近づかせないで、 情報に近づかせたとしても情報を取り出させない、情報を取り出させたとしま
186:10 しまったとしても、情報を永続利用させないということに相当します。この三段階ですね。
186:19 それを見た上で、ランディングゾーンどのように扱われますか？ というのも見ておきましょう。で、まず運用管理サブスクリプション、これですね。
186:27 お城のページで紹介するんですけども、ここでKey Vault扱う場合、 こうしたらいいですよというベストプラクティス。
186:34 ここでまずポリシーとして定義をしておきます。
186:37 そしてアプリケーションがまあKey Vaultとか使うようなケースであれば、 そのポリシーがアサインされてそのポリシーに従ったKey Vault運用するようにまあ強制するということができます。こういう形でランディングゾーン使われております。定義されております。まあKey Vaultの概要ですが、まあこれはもう大丈夫かなとは思いますが、まあキーシークレット証明書、まあこういったものを安全に管理するサービスです。まあ、ロールベースでアクセス。制御も可能ですし
187:07 監査のログも残せます。 そしてハードウェアセキュリティモジュールこういったものも利用できますね。
187:15 なんでまあこれ？一言で言えばですね、 もう厳重管理された監視カメラ付きのもう金庫みたいなものにイメージすると、
187:23 まあわかりやすいかなと思います。ただしですね。まあ、金庫を使いますと言ったとしても、 金庫を野晒しにしていればもう全然安全とは言えないですね。
187:33 で、安全に運用するためのプラックです。これもあのちゃんと定義されております。で、 これらが守る、
187:40 守られるようにポリシーを運ポリシー適用進めていくということが必要です。 ただまあこれは詳細は一旦ここではスリップいたします。では本節のまとめです。
187:52 キーボールドを正しく使ってシークレットなどを保護しましょうということです。
188:00 では続いてAzureデリケイテッドHSM、これを見ていきます。これ、 ちょっとややこしいんですよね。で、AzureデリケイテッドHSM
188:10 これ何かまず導入にあたって、まあ、この例を見ておきましょう。まずイラストではですね、 このこだわりの強い経営者いますね自社ビルを建てたことを満足げに語っています。
188:22 現代においてですね、ビジネスをするために自社ビル、わざわざ建てる必要ありますか？ っていうと、まあ必ずしも。
188:30 ないですね。普通にビジネスをするだけだったら、オフィスペナントを借りて、まあ、 多少工事したらもうオフィスとして十分に機能します。で、そのオフィスもですね、
188:42 きちんと施錠さえしていれば、通常は安全上の問題ありません。ただですね、 こだわりが強いという場合どうかなんですが、例えばですね、いや、
188:51 オフィスの上の階からドリルで穴を開けて、 うちのスペース侵入しようとしてくるものいるかもしれへん。
188:59 で、場合によっては排気口から侵入を試みるものいるかもしれへんと考える人、 あるんですね、実際、まあ本当にターゲットを徹底して攻めようと考える場合、
189:09 そこまでする人っていうのは出てくるかもしれないんですね。 これらまあ対応するにはですね、もう普通のビルじゃ無理だということで、
189:18 もう自社ビルを建ててですね。もう完璧な対策をするほかなくなってきます。
189:24 で、ITシステムにおける極めて厳格なコンプライ、 コンプライアンス要件でもですね、
189:31 まさにこういうレベルでリスクを認識してくださいというふうに求めることあるんですね。 そういう極めて強いこだわりのコンプライアンス、保険とか、
189:41 そういったものに対応するために、こういったデリケーテッド、 HSMようなサービスがあります。では概要を見ておきましょう。まあ、
189:50 キーワードはですね、物理レベルの分離です。
189:54 まあ、顧客専用のお客様専用のHSMが物理的に用意されます。なんでまあ、 まさに貸しビルのテナントに入るんじゃなくて、
190:03 もう自社ビル用意しますというようなもんですね。その上で完全な管理制御を可能とします。 なのでまあ、こだわりの強い厳格な要件にも対応できるということになります。
190:17 で、ユースケースと注意点なんですが、 まあユースケースこれはもうあの厳格な要件対応ということで理解をしておくと良いかと思います。で、注意点の方が重要かもしれません。何よりですね、コストが高くつくで、管理が複雑という点が挙げられます。特にですね、これ適格性要件がかかれますので、まあ必ずしもすべてのお客様に推薦で推薦できる商品と。
190:45 いうわけではないないということになります。この点ご注意ください。一方でですね。 参考として、キーボールドにもHSMがございます。これもですね、
190:59 HSM使用できるんですが、まあキーボールドとまあ同様な運用が可能になっています。
191:07 あの物理的な分離というのはされてはいないんですけれども、 このHSMインスタンスというレベルで分離が行われているんですね。まあ、
191:16 内容結構複雑なんですけども、論理的な文理が果たされているということです。 ですので、まあ、テナント分離という要件は、
191:24 これは満たされているというふうに考えることができます。 これもぜひ検討してみるとよいかなと思います。
191:34 では本節のまとめです。厳格なセキュリティ要件がある場合は、HSMによるキー管理、 これを検討してください。ではえ、Azureコンフィデンシャルコンピューティング？
191:46 これも見ていきましょう。これもですねえ、イラストから概要を掴んでいきます。 三枚のイラストを左から順に見ていきましょう。まず左側。え、この人がですね。
191:58 まずタスクを工場に依頼しようとしています。
192:02 封筒に指示を書いて、まあ誰にも見られないようにしつつ、それを工場に投入しています。 で、この工場にはですね、なんとは人が通れる入り口がないです。
192:11 もう完全に外から見たらもう鉄の塊なんですね。なんでまあ、 非常にこんな小さなポストからその依頼を行っています。エントランスはないです。
192:20 さらに言えばですね、 工場の経営者もここに入るための手段を持っていないというような状態です。
192:25 もう完全にシャットアウトされているんですね。で、中央バスの工場の中で。す。
192:30 ここでは自立したロボット君がですね、依頼をこなしている様子がわかります。で、 右側ですね、右側でタスクを依頼した人が結果を確認しに来ています。で、
192:41 本人確認のためにカードキーをかざすと、まあ、関連する処理の完了証とか、 あるいはまあ処理結果が発行されました。まあ、この例のようにですね、
192:51 データの処理中であっても、それらがまあ接種改ざんされないようにするための、 まあ一連の基盤ということで。
192:59 まあ、これを提供するのがコンフィデンシャルコンピューティングの目的です。 これについて理解するために、最初に
193:08 データ保護のライフサイクル理解しておきましょう。暗号化はですね。 まあ三つの状況があり、適切に行われている必要があります。
193:17 一つ目はデータ保管時ですね。まあ、 デバイスにデータが保存されている状態での暗号化で、2つ目は転送中ですね。
193:25 ネットワーク転送中も暗号化をする。これはまあ、。
193:29 インターネットのhtpsの通信とか、これはもう身近な例です。そして、 使用中の暗号化処理中のデータも暗号化されている必要があります。
193:37 これが暗号化されていない場合ですね。例えば、 仮想マシンのサービス提供者がそのスナップショットを撮って、
193:44 そのメモリー部分を読み解くことで、 データを抽出するということができてしまうことになります。そうするとですね、
193:50 クラウドサービス提供者、まあ、通常そのようなことをしませんけれども、 理論的にはそういう形でデー。タ。を奪うということができてしまう
193:59 で、そういう状況だと、例えば個人情報を扱うとか、まあコンプライアンス要件上、 問題になってしまうことがあるんですね。で、
194:08 このコンフィデンシャルコンピューティングの概略ですね。で、見ておきましょう。 キーワードはTEですね。まあ、TEとして、
194:18 確実に他と隔離された領域というものが、計算領域というものが用意されます。 この中で機密度の高い処理を実行しているというわけなんですね。
194:30 ただ、ここで重要なのがですね、 それが本当に正しく行われましたかというのを確認すること。これが重要です。
194:36 処理が本当に改ざんされていないんですかね、それ改ざんされてますんって、 あんたが言ってるだけじゃないですかということになると、
194:44 ちょっと信頼して処理に任せていいかわからなくなってしまいますんで、まあ、 秘密計算が目的。果たしてというふうに言えなくなっちゃいます。
194:52 改ざんされていないということを保証してほしいんですね。
194:56 そのために公正証明というサービスがありまして、 それを使ってまあ処理が改ざんされていませんよということを確かめることができるようになっています。公正証明ですね。で、このコンフィデンシャルコンピューティングのユースケースとして、ここでは三つ挙げておりますが、まあ、一つだけ挙げておきましょう。まあ、機密度の高いデータ処理ですね。これは特にまあ、クラウド事業者ですら処理中データ見えないようにすると。
195:24 いうことがポイントになります、クラウド事業者からは見えますという状態だと、 まあコンプライアンス要件として問題になることがあります。なので、
195:34 クラウド事業者に悪意がないデータを摂取しないということを証明するのはやはり困難ですので、まあ、そもそも処理中も隠しておきましょうね、ということが重要になります。そして、マルチパーティー計算もユースケースとしてあるんですが、今回はスキップさせていただきます。では本節のまとめです。
195:54 まあ、特に処理中のデータが暗号化について焦点を当てて紹介しました。では、。 データ保護ソリューションの比較について。まあ、
196:03 ここまで扱ってきた製品を表で比較しているんですけれども、 ここでは一旦詳しく見ることはせずに、今回はあのスキップさせていただきます。まあ、
196:13 コンフィデンシャルコンピューティングのみ、まあ、少しあの区分が異なりますんで、 これはあの見るときは注意をしてください。
196:23 では、本章のまとめです。この章では、 安全にキーやシークレットを管理する方法、そして処理を安全に進める方法について、
196:33 まあ、開業レベルで確認をしてきました。はい、 では前半パートは以上となりますはい。それでは時間になりましたので、
196:45 再開させていただきます。それでは後半パート第五章か七章ですね。 やっていきましょう。
196:52 第五章はcspmとcwpp、 ディフェンダーフォークラウドについて取り上げていきたいと思います。
197:01 でもこちらこちらですが、概要をここで見ておきましょう。 ディフェンダーフォークラウドの概要、そしてcspmの意義、そしてcwppの効果え、
197:12 確認をしていきたいと思います。まずですね、。 ディフェンダーフォークラウドの全体像、これを確認していきましょう。
197:21 ディフェンダーフォークラウド、理解するにはまあ、 企業のセキュリティにとってあるべき姿というものを知っておくと良いかなと思います。
197:31 そしてですね、これはあの健康に例えると非常にわかりやすいんですね。 健康の秘訣は何だろうかで、これに対する模範的な解答はですね、まず予防すること。
197:42 そして病気になるとしても早期に発見して治療し、回復すること。
197:47 あ、大きな病気を患わないように配慮を尽くすということなんですね。で、 このコンセプトっていうのはセキュリティでも同じです。
197:56 インフラのセキュリティ面での健康を実現するために、 このディフェンダーフォークラウドが役に立つんだということですね。では、
198:05 全体像を簡単に見ておきましょう。ディフェンダーフォークラウド、まあ、 三つの柱をここでは。掲載しております。セキュリティ体制管理でワークロード保護。
198:16 デブセックオプス支援ですね。これらの機能をAzureだけではなくて、 オンプレミスや他社のクラウドも対象に含めて適用できるということになります。
198:28 シーエスピーエムはですね、これはクラウド環境全体をまあ、継続的に評価して、 まあ問題がないか監視し続けるというようなものです。で、問題があれば、
198:40 対応の垂直策とかも提示をしてくれます。
198:44 Cwpp。これは 各種のクラウドワークロードをまあ脅威から保護するというものですね。
198:52 そしてデブセクオブス支援。これは本講座では内容を含んでおりません。 快楽程度ここに記載はしております。では
199:02 cspmとcwppを次この章で確認をしていきますが、ああ、ここでああ、 ランディングゾーンにおける役割も確認をしておきましょう。
199:12 ランディングゾーンにおいてはですね、 プラットフォームランディングゾーンそしてアプリケーションランディングゾーンに至るまで、まあ、すべての顔料にですね、ディフェンダーフォークラウドが隠れておると配置されておるということになります。ここがもう特徴かなと思いますね。まあ、全体の状況を知って保護するんだという場合は、もうあらゆる場所にそれを配置しておく必要があるということになります。で、まあ、至るところにまあディフェンダ。ー。フ。ォークラウドの影ありという状況に持っていくことが重要です。
199:43 まあ、簡単ですが、まとめです。ディフェンダーフォークラウドはまあ、 Azureに限らず、
199:49 あらゆる場所で幅広いリソースを保護するソリューションなんだということです。では、 シーエスピーエム。まあ、クラウドセキュリティ体制管理について見ていきましょう。
200:00 シーエスピーエムクラウドセキュリティ体制管理の概念もこれも 健康管理に例えて理解をしておきましょう。最初にですね、
200:08 健康の秘訣を質問していた左側の人物。
200:11 まあ、毎年欠かさず健康診断を受けてきたみたいですね。 そして程度の異常が見つかった同士もあるかもしれないんですけれども、
200:18 まあ都度改善のために活動して、 まあ治療を受けることで大きな病気を患うことがなかったということです。で、
200:24 このシーエスピーエヌが目的としているのは、まさにこの状況なんですね。 ディフェンダーフォークラウドがもうこれをアイティー空間においても可能にするということになります。
200:36 ではcspm概要を見ていきましょう。まあ、これはまあ、 三つの項目で示した通り、まあセキュリティの健康診断です。まあその目的はですね、
200:46 こちら一つ目にあるように、まあ設定ミスとか脆弱性とか、これをああ、 こうしたもの有無を評価、可視化修正するということがあります。まあ、こうすることで、
200:56 まあ問題が発生する前にできる限り対応をしましょうということですね。右側、 これはあのダッシュボードの一部のスクリーンショットを示しています。
201:06 まあ、 Azure以外のクラウドも含めてセキュリティスコアの数値が示されております。
201:12 まあ、この画面から見る限りですね。 まだちょっと改善の余地があるかなという状況ですね。このセキュリティスコア、
201:21 基本的にはですね、まあスコアを高めるために、 まあ推奨に従って活動を行っていくというものです。ただ、あの注意点としてですね、
201:30 個別のシステム要件に合わせて。
201:32 改善のアクションは本当に妥当か確認をする必要はあります。まあ、 理想的にはこうなんだけど、まあ、ビジネス上の何らかの要件から、
201:41 今は対応がふさわしくない、あるいはまあ、システムの詳細仕様上、 その部分を変更するっていうことは受け入れられない。まあ、
201:50 こういったふうに何らかの事情があるかもしれないので、まあ常に確認が必要です。 そしてもう一つ重要なのはですね、
201:58 これは継続的に維持改善する指標だということですね。
202:02 あの一番良くない使い方はですね、 システムリリースの直前にスコアをまあ例えば百まで上げました。で、
202:08 その後全く確認をしなくなりました。これが一番良くない使い方なんですね。なんでまあ、 例えば、健康診断前にまあ2 3週間食事制限をしましたです。
202:17 検査の数値上がりましたよっしゃあっていうことで、 その後に暴飲暴食続けてしまったらですね、全然意味がない。
202:24 健康にならないということですね。セキュリティでも同じです。
202:30 他にまあリスクベースの推奨事項の確認ですね、 これも具体的にこういうふうに修正するといいですよみたいな提案も行ってくれます。で、
202:37 まあリスクレベル、まあこれはミディアムとか書いてますけど、 そういったものも書かれておりますね。まあ、こういった、
202:45 まあリスクレベルに基づいて、優先順につけられてますね。担当者がアサインされて、 まあ問題解決しますよという時に、まあ、この優先度の情報も参考になります。
202:57 で、こちら例ですが、これは詳細な内容はスキップさせていただきます。そして 次は攻撃パス分析ですね。これ可視化を伴う分析も可能です。まあ、
203:06 重要な資産がどこかにあるとして、 まあそこにはまあどういう経路でたどり着けるかっていうのを可視化できます。まあ、
203:14 あの個別のリソースだけ見ると、まあ一見してまあ問題なさそうかなという場合でも、 まあ俯瞰してみると、一定の経路をたどればですね。
203:23 外部から重要資産にたどり着けるといったこともあり得るんですね。なので、 リスクのある経路を知って、それを断ち切るというための対策をとることができます。
203:33 あとまあ、規制コンプライアンス殉教状況の評価まあ各種のですね。まあ、 主要な規制コンプライアンスの情報がまあプロダクトに組み込まれております。
203:43 なんでまあこちら。。現在の準拠状況を評価したり、 まあレポートを生成して監査に備えたりとかいうことで活動に役立てられます。
203:52 ただしですね これらコンプライアンス準拠を保証しますよということまで行いませんので、まあ、
203:59 最終判断お客様側に委ねられます。まあ、ここまでの内容を振り返るとですね、 まあ、概ねこの図のように、まあサイクルを回しているというふうになります。
204:10 まずは状況を可視化します。その内容を人間が評価します。 評価した上で改善策を実行します。まあ、この繰り返しですね。一度じゃないです。
204:19 繰り返しです。
204:20 この繰り返しがシーエスピーエムにおける活動ということになるんですね。 そしてまたあのすべてを、まあ、
204:26 リレンダーをクラウド任せにできるというわけではないです。 場合によってはこれは改善した方がいいですよと言われても、
204:32 そうしない方がいいケースもありますんで、 まあこれはサービスはあくまで支援する立場なんですということは理解しておいてください。
204:40 それでは本節のまとめです。 シーエスピーエムを使ってセキュリティを維持し続けまし。ょ。う。ということでした
204:48 でも、続いてどんどんいきます。 クラウドワークロード保護これも概略を絵で見ておきましょう。イラストでは、
204:55 花粉症に悩まされている人物がいますね。もう花粉は決まった時点に飛ぶものです。 もうそれ自体を根絶することはもうできません。かといって、まあ不快な症状、
205:05 これを患いたくはないんですよね。 そういった時にはもうマスクをつけて防護して症状を緩和するといったことが
205:12 有効です。
205:14 え、セキュリティの世界においても、まあ、大規模な攻撃キャンペーンであったりとか、 あるいは悪意ある攻撃チャンネル、攻撃思考、これはもうそもそも根絶は無理です。なので、
205:24 まあ対策が求められるんですけれども、まあ、 こういった時にあたかもマスクをするかのようにですね、まあ、比較的手軽に、
205:30 でも効果的にまあリソースを保護するという手段が提供されています。これがまあ、 クラウドワークロード保護のコンセプトになっています。
205:40 このクラウドワークロード法の概要ですね。まあ役割の区分、これらは大きく二つ。 ここでは掲載をしております。まずリアクティブな脅威防御。まあすなわち、
205:51 まあ問題発生と応募し、 状況になった時にまあそれらを検出してくれると不審な活動があったら検知してくれる。
205:59 そして関係者に通知して、まあ一部対応実施できることもあります。そして、 プロアクティブな問題発見と対応。
206:07 まあ、ワークロードが脆弱になっていないか、まあ設定とかを継続的にスキャンして、 リスクを検知で、
206:13 リスクのある部分が見つかったら対策案を提示するということをしてくれます。で、 以降はですね、
206:19 まあ具体的なリソースタイプごとのまあサービス確認をしていきましょう。で、 いくつか紹介します。ここではまあああ三つですね、三つ紹介していきます。で、
206:29 まず最初にディフェンダーフォーサーバーズまあ名前の通りですね。 もうサーバーマシンの保護を行。い。ます。
206:37 まあポイントはですねAzureの仮想マシンだけではなくて、 まあAzure以外のリソースにも
206:44 午前中で見たAzureアーク介してですねダブルエスまあクラウドでオンプレイです。 いろいろ管理できるということですね。そう、
206:52 午前中もやりましたAzureアークここで活躍してくれるんですね。 まあ機能はいろいろあるんですけども、
206:59 まあ脆弱性のスキャンとかがまあ一番わかりやすい例かなと思います。プランは 二つあります。
207:06 まあプラン二の方ですね。こちら上位プランなんですけれども、まあ、 いろいろ位置にはない機能が。追加されております。まあ、
207:14 エージェントレスのスキャンであったり、ジャストインタイムのアクセスとか、 まあより高度なセキュリティ要件だったり、まあ、
207:22 ワークロード要件対応するための機能が用意されております。で、ここではですね、 まあ例として、エージェントベースとエージェントレスの違いについて、
207:32 ちょっとだけ確認をしておきましょう。
207:34 エージェントレスは、これはまあ、サーバーへエージェントをインストールしません。まあ、 軽量のプログラムがエージェントなんですけども、それをインストールしません。
207:43 代わりにまあ、サーバーのスナップショットを作成して、 スナップショットに対してスキャンをかけるということをします。こうすることはですね。
207:50 まあ、サーバーにスキャンの負荷をかけることがなく、 まあ検査を実行できるということになります。ですので、まあ、例えば
207:57 負荷がめちゃくちゃ高い。サ。ー。バーもう常に高いサ。 ーバーとかがあるという場合はこのエージェントレスにする方がまあ安定稼働
208:04 保証できるということになります。では ディフェンダーフォーストレージまあこちらも名前の通りですね。
208:13 まあストレージの保護を行うものです。まあマルウェアスキャンであったり、 まあ異常なアクティビティ、異常なアクセス検知して対応することが可能です。で
208:25 ディフェンダーフォーSQL、まあSQLデータベースの保護ですね。 まあこれはまあ脆弱性。
208:33 あるいは設定ミスとか、まあこういったものを評価して、 まあリスクを検知するというものです。あとまあ、一部の攻撃ですね。
208:41 ここではまあエスキューエルなんでエスキューエルインジェクションとかありますけども、 まあ、こういった一部の攻撃にもまあ対応することが可能です。では、
208:52 本節のまとめです。実稼働中のサービスを保護するというための機能を確認してきました。 で、本書のまとめですね。ディフェンダーフォークラウド、見てきました。
209:03 健康の秘訣ですね。健康の秘訣は、予防、早期発見、治療、そして回復です。 このシーエスピーエムとシーダブルピーピー。これはうまく使って、うま*。
209:14 *れらの健康の秘訣実現するために、まあ取り組み進められるようにできます。では、 次にいきます。第六章シームトストアMicrosoftセンチネルについて。
209:30 目次はこちらですが、概要をこちらで見ていきましょう。センチネルの概要、 そしてシーム機能、ソアー機能の順で確認をしていきます。じゃあまず、
209:39 センチネルMicrosoftセンチネルの概要についてです。 例によってイラストを確認していきましょう。まあ、昨今ですね、まあ、
209:49 インシデントが発生することなく過ごせる企業っていうのはですね、 もうほぼないと言っていいです。
209:56 なので、まあ当然ながら、 まあ脅威への備えっていうのはもう万全にしておく必要があります。で、
210:03 この警備員の人物が。ああ、フルアーマーですね。警備員の人物が話しているように、 まあ問題をまず検知すること。そして検知したものを知らせることで、
210:14 被害を広げないための初動対応をしっかり行うこと。 これらがインシデントへの対応では必要になってきます。
210:23 センチネルではですね、こうした点を支援するということが可能になってきます。まあ、 実際にどういったことを行うか、これは図で概略的に理解をしておきます。
210:35 この図ではですね、まあ、セキュリティ運用のまあ、ワークフローの概要を描いています。 左側、これはシームの部分ですね。シームの部分では、
210:46 まず多様なデータソースもういろんなところのデータソースからログを収集しています。
210:53 そして次にログを分析するんですね。それを分析して、指標同士の関係性とか、 そういったものを紐解きながら脅威を発見します。で、
211:04 問題が実際にあるなあと判断できるんであれば、それをインシデントとして起票します。 です。これこれ以降、右側はソワに当たる部分ですね。ソワでインシデントありますんで、
211:18 まあ対応の担当者をアサインしたり。
211:22 で、重大な問題であればですね、もう即座にアカウントをロックしたりとか、 まあ様々なアクションを考えられるんですけれども、まあそれらを。
211:31 ソアでは自動化ができます。アソアのまあ約、 まあオードヘンションなんて書いてあるんですけど、
211:37 まさに自動化対応できるというものですね。まあ、 これら一連の運用をセンチネルではカバーしています。
211:43 では主な特徴をここで確認しておきましょう。 まずはクラウドネイティブであるということですね。
211:50 まあ性質上まあ膨大な量のログ取り扱うので、まあクラウドであることが有利です。 そして高度な脅威検出、
211:58 これはまあルールベースのまあ検出以外の機能もありますよということですね。 それで多様なコネクター分析ルールこれはコンテンツハブですとか、
212:08 こういったもの標準のコネクター利用できるか。まあ、 エージェントやAPI使うことで、まあ多様なデータソースに対応することができます。
212:21 そして運用支援の機能ですね。まあ、インシデントの管理機能とか、 あるいは競技ハンティングとかを使って、
212:29 まあ競技ハンティングによって発見した問題の種に当たるもの、 これはをまあもとにスムーズにアラートを作成できるという機能もあります。
212:38 あとはまあ自動化対応ですね。人の判断を必要としない部分は、 まあ極力自動化を行いましょう。
212:47 で、ランディングゾーンにおける位置づけ、これも確認しておきますね。で、 これはポイントになるわけですね。もうあらゆる環境のセキュリティ関連のログ、
212:58 この一元管理する場としてセンチネルを取り扱うということですね。 もうあらゆるサブスクリプションにデプロイされたリソースのログ。
213:07 これらはもう単一のセンチネルに集約されます。この構成をとることが一番重要です。
213:13 間違ってもセンチなる方、いろんなサブスクリプションに配置しないでくださいはい、 一つのサブスクリプションで一元管理するというのが重要です。え、
213:22 収集できるデータの種類についてなんですが、えっと、これはまあ、 Microsoft製品であったり、まあAzureであったり、これはもう
213:31 当然収集できるとしまして、まあそれ以外にも、まあ、 オンプレのネットワーク機器であったり、サーバーであったり、あるいはまあ、
213:39 サードパーティのクラウドだとか、あるいは？サースで。すね、
213:43 まあ、構成次第であらゆるところからデータを集められます。 では次にポストの話もしておきます。まあ、
213:51 ここからしばらくコスト関連の話題を続けます。コストについて考えるときはですね、 まあ、まずはあのこの右側の図でデータの移動の様子を理解しておくと良いかなと思います。
214:03 まあ、これはデータの移動が伴うアクションがですね。まあ、 主なコストと関係していきます。まずはまあデータの取り込み。
214:13 それからデータの保持ですね。それから、まあ、長期保有が必要だという場合は長期保有。 まあアーカイブしてで、もし必要であれば一時的に復元をするということ。そして
214:25 分析をする必要があった場合はデータのクエリを行う。まあ、 これらアクションにかかるコストが、
214:32 まあプランによって変わってくるということになります。そのプランについてなんですが、 このログプラン、これは二つ紹介しておきます。
214:43 アクティブな分析で使うまあ分析ログ、 それからまあコンプライアンスのための超表紙とかで使用する補助ログですね。まあ、
214:51 分析ログについては、まあ、あの取り込みのコストとかは当時高コストになっている分、 クエリのコストはなしということになっています。なのでまあ、
215:02 分析を積極的にできるプランであるということになります。で、補助ログはですね。 まあえっと、長期保持の要件を満たしやすい条件が揃っております。
215:13 まあ状況事業ですね。まあ、ほぼほぼでコスト最適化のポイントなんですが、 まあここでもまあ基本はまあ、データの移動を伴うアクションを軸にして考えていきます。
215:23 データの取り込みについてはですね、これはもうあのプランを正しく 選びましょうということにつきます。あとですね、
215:31 フィルタリングのルールこれを運用するということ、そうすることで、 まあ本当に必要なデータだけを取り込むようにしましょうということですね。
215:41 いらないデータもとりあえず取り込んでいると、結構それでお金かかってしまいますんで、 必要な必要なデータだけを選んで取り込みましょう。そして
215:52 データクエリのコストですね。これも適切なプラン選択が基本です。まあ、 アクティブに分析するかどうかがまあまあ概ね限りになるかなというところですね。
216:03 そしてデータ保持コスト。まあこれもまあ当然ですけれども、 必要十分な期間だけ補充をするということですね。
216:11 これも当たり前の話かなというところです。そして最後は特典の活用ですね。まあ、 企業内の膨大な量のログデータこれをコンスタントに取り込み続けるという場合は、
216:24 まあ条件を満たしていれば、まあ割引された金額で利用できるようになります。まあ、 いわゆるコミットメントティアによる割引ですね。
216:34 え、Microsoft 365の1部プランでもまあ、 え割引適用されることがありますんで、こちらも。え、ぜひチェックしてみてください。
216:43 ではえ、本節のまとめです。Microsoftセンチの概要を見てきました。まあ、 基本の機能であったりとか、まあ対応するログの種別であったりとか、
216:51 まあコストの体系であったりとか、まあ、 スチームナソファーの担当範囲も含めて理解しておくといいかなと思います。
217:02 ではログの収集と活用について。まあ、CMの機能ですね。これを見ておきましょう。 インシデントへの対応にあたってはですね、ログの収集、
217:12 これはもう非常に重要な位置づけにあります。というのもですね、 あのデータがそもそも揃っていなかったんですね。問題の発生に気づくことすらできません。
217:22 なのでも対応も進まないということになってしまいます。なので、まあ、 体制の整備にあたってはですね。
217:29 まずはとにかくデータを拾い上げて一元管理する、 その上で分析を開始するという流れが大事です。これはもう鉄則ですね。これを意識しつつ、
217:40 できることを確認していきましょう。最初に確認するのはですね、コンテンツハブです。 まあ、実務においても、まず最初に見に行くべきものはこれになるかなと思います。
217:55 このコンテンツ、ハブではですね、まあデータ収集用のまあコネクターであったり、 まあ分析のワークフローであったり、まあこうしたものが、
218:03 まあ何らかのテーマに沿ったソリューションという形でパッケージ化されてますんで、 まあ検索とかもポータルからできるということになってます。まあ特にですね、
218:12 まあ豊富な例を含んでますんで、まずはもうここで、 自分に必要なものがあるか探すという運用になっていくと思います。
218:22 で、コンテンツハブで目的のものが見つからない場合はですね、 自分でログ収集の手段を確立します。で、その方法の一つが
218:30 Azureモニターエージェントを使うやり方ですね。で、この方法はですね、 まあエージェント、まあ仮想マシンであるとか、あるいはまあ、
218:38 オンプレとかのサーバーにまあインストールして使っていきます。ただですね、まあ、 単にインストールするだけでは、まあ、あのエージェントもですね、
218:47 何を集めればいいんですかということになってしまうんで。す。が。
218:51 ここであのデータ収集ルールというものが出てきます。 データ収集ルールこのルールを使って、
218:57 まあ収集するデータの詳細を定義していくということになりますね。で、 ルールを定義した上で、
219:03 それがエージェントとまあ個別のエージェント関連付けられることで、 まあデータの収集体制整っていくという流れになります。
219:13 それからですね。先ほどのコスト最適化の話題で、 まあ必要十分なデータ集めるべきですねというふうにしましたけれども、それはまあ、
219:22 このデータ収集ルールを適切に設計しましょうよということになります。もう一つはですね、 API経由のデータ収集ですね。まあ、レストAPI経由して、データ集めますと、
219:33 まあ、これはまあユースケースはですね、まあこういったところかなと思います。 エージェントのインストールを自由にできないとか。
219:42 まあ、コネクターもないという場合ですね。 まあ特にサースのサービスとかがまあ該当するかなと思います。そういった場合はですね、
219:51 もう自分でAPI接続するように設定をそこでまあ行っていただくということになります。 まあ、データ収集ルールを使うという点が、
220:00 まあ概ねAzureモニターエージェントと同様ですね。 ここでもルールは設定しましょうということにはなっております。え、こうしてえ、
220:09 収集してきたデータはですね、まあ当然。
220:12 まあ、蓄積するだけではですね、あの価値を作り出すということはできません。 僕はやっぱり分析されてこそ意味があるんですね。で、活用方法の一つとして、
220:22 まあ分析ルールというものを作って運用するということが挙げられます。 この分析ルールというやつはですね、まあ基本的にはパターン検知のためのものですね。
220:32 パターンを検知するための、まあケーキューエルクエリーというものを定義していきます。
220:41 で、例をいくつか挙げておりますけれども、まあ、 クエリがシンプルになりそうなのは2つ目の例ですかね。まあ、
220:49 通信のプロトコルやポートがもともと提起していたものと合致していないというルールこれをまあ、コードkqへのクエリーコード書くことで、パターンを定義する。まあ、そうしたケースをまあ、あ、ぶり出せるな、クエリを作成していくということになります。で、まあ、この右の図もですね、ここまでの内容を説明したものです。
221:11 チェックしておきたいのはですね、 アラートが複数束ねられてインシデントとなっているところですね。まあ、
221:18 関連するものをグループ化して、 インシデントとして起票するというアクションを設定しておくと、まあ、
221:25 インシデント発生時の対応漏れが防ぎやすくなります。特にですね、 あのオペレーション担当者は大量のアラートと向き合うことがまあ、
221:34 だいたいあります。そうするとアラート疲れと呼ばれる現象が発生してくるんですね。
221:39 そうなると、もうあ、 このアラートはもう関係なさそうやからわというふうになってきてしまうんです。
221:45 これはもう人の精神的なもので、心理的なものとしてもう存在すると、 ただそういうふうにならないように、アラートをまとめられるようにしておく。で、
221:53 インシデントとしておくと、まあ意味のある情報の単位でまとまってくるので、 そうしたこともオペレーション調理ちょっと楽になるということになります。では、
222:02 本節のまとめです。ログを収集して基本的。な。分。 析パターン運用をしていきましょうということを紹介しました
222:10 次がインシデントの分析と調査です。 インシデントがここまでの流れで作られました。
222:18 それらを調査するという流れを確認していきましょう。ではイラストですね。 このイラストで見ていくと、ここではですね、まあ、
222:27 刑事ドラマの事件対策本部みたいな光景が描かれています。捜査官たちがですね、 まあ、現場に残された商工品を収集して、まあそれらを。
222:38 一箇所にまとめて眺めています。ですね、一つ一つの証拠言います。 それは個別に見るだけでは十分な情報が得られないことが多いんですね。まあ、
222:47 ただ単にあの時計一つとってみても、なんか単なる土のついた時計ですね。 以上で終わってしまうということもあるんですが、ただ、こうして俯瞰してみると、
222:56 お互い結びつけて考えることが浮かび上がる事実というものがあったりします。そして、 そういった形でわかったことを、まあ、このホワイトボードに分析結果と。し。て。
223:05 ここではまあ、書き出していますね、
223:08 まあ、こうして事件をめぐる推理とか、まあ調査を進めているということになります。で、 同じようなことはですね、
223:14 サイバーセキュリティにおけるインシデント対応でも発生するということですね。まあ、 各種ログやアラートといった、まあ膨大なデータがあるんですけれども、
223:23 それらを意味のある形で束ねる束ねて、まあ、複数操作の情報を統合した上で、 その上で原因分析であったり、対応方針の策定であったりというのを進めていきます。
223:32 このイメージをまず持っておいて。く。ださい
223:39 で、インシデント管理調査支援機能ですね。これを見ていくと、 まずアラートを集約してインシデントとする点。これはまあ前の説で見てきました。で、
223:47 管理面でいくと、まあ状況を管理して記録する。状況を記録して管理する。 そしてワークフロー系の、まあ各種機能ですね、まあ通知したりとかアサインしますとか、
223:57 そういったものを提供してくれます。で、 あとまあ調査にあたっての参考情報も提供してくれることがあります。
224:04 まあ、 こういう形で必要な情報がセンチでのプラットフォームにまとめられていくというイメージですね。それで脅威ハンティングです。ここまで発生したインシデントへの対応について取り上げています。え、右の図で言えば、まあ、発生した問題の分析を行うのは、まあ、ここまでのインシデント対応の部分ですねえ、脅威ハンティングも可能だと。え、この脅威ハンティングは潜在的な脅威の発見に相当します。
224:32 まあ、いわばインシデントの種に当たるものですね。これを発掘して、 それが芽を出してしまう前に刈り取るということを目的としています。で、
224:41 方法としてはですね、まあ、 コンテンツサブのケーキウエルクエリこれを運用したりとか、
224:47 あるいはまあ自分の洞察に基づいてクエリを作成したりとかいう方法がとられます。 え、クエリ結果とかによってですね、これは有効そう、
224:56 有効性ありそうだなということであれば、それを。
224:59 アラートという形で設定して、問題発生に備えられます。まず脅威を発見します。 そしたらそれをアラートにします。アラートにすることで、
225:07 もし本当にそれが問題が顕在化した場合は、それに気づくことができますと。なのでまあ、 予防や早期発見につなげる試みもできるということですね。まあ、
225:16 やっぱインシデントは起きたら対応するっていう。 まあ待ちの姿勢だとちょっとどうしても良くないので、
225:22 まあちゃんと予防的な要望もできるようにしておきたいとい。う。ところです
225:30 で、次に機械学習エンジンにより検出される異常について。 これも簡単に見ておきましょう。まあ、ここまではですね。まあ、景気をやるとか、
225:39 主にパターンに合致するかどうかで異常を判定してきました。ただですね、現実にはまあ、 より複雑な要因が絡み合います。まあ、パターン定義をまあ多数用意するというのでも、
225:50 まあいいんですけれども、ただ、それだと管理が複雑になってしまって、 まあ細く漏れも生じます。
225:57 そうなると、まあ、こうした場合ですね、 機械学習ベースの異常検出っていうのが有効になったりします。なので、まあ、
226:05 普段の振る舞いであるとか、まあ組織にこういうような正常パターンまあ、 こういったものを学習によって認識して、
226:13 そこから外れるものを異常とするという内容ですね。まあ、 こういったものを対応が可能です。で、
226:20 最後に自動対応についてインシデットが発生した時に、まあ一部の。
226:25 処理っていうのは、まあ自動化することが望ましいということがあります。例えばですね、 インシデント対応の担当者、アサインしますとか、
226:34 まあ定型的な処理を行いますということですね。これはまあ自動化した方がいいでしょう。 単純作業ですね。あるいはですね、
226:41 重要なアカウントへのサインインアラートが発生したという時、この場合も 緊急対応が必要ですよね。この場合は素早**のアカウントを一旦無効化するとか、
226:51 対応が必要なことがあります。
226:54 その場合、自動化しておいたら、まあ人の判断が不要なので、まあ素早く迅速に、 まあ無効アカウント無効化するとか、そういった対応をとることができます。まあ、
227:03 こういったものはですね、プレイブックという形でまとめることができます。で、 この作成にあたってはですね、Azure logic appsという、まあ、
227:12 ノーコードの。AzureのアプリですねAzureサービスですね、 これを使うことができます。まあ、ノーコードツールは、まあ、
227:20 だいたいアクションとかコネクターとか。
227:23 まあ、非常に豊富に用意しているので、まあ柔軟に自動化フロー定義することが可能です。 まあ、草案の定義最初見てきたんかもしれませんが、まあ、
227:34 オートメーション含まれてますんで、 まあ積極的に自動化を含めて効率化をしましょうということです。では
227:42 本節のまとめです。まあ、ログの蓄積で終わらずに、 まあ実際の活用方法を理解して問題発生時に対応できるようにしましょうということです。
227:55 では、本章のまとめですね。本書ではセンチネルの概要、 それから料金体系を見てきました。で、シーエムの機能、そしてソアーの機能。
228:07 これもチェックをしてきました。それではではですね、最後の章、 第七章ですね。
228:15 こちらはセキュリティコパイロットについて取り上げていこうと思います。
228:24 こちらですねで見ていきますが、あ、概要はこちらで見ていきましょう。 上がりをホームページ見ておきますが、特徴とコスト構造、そして
228:35 基本的なユースケースそれから Microsoft製品の他のMicrosoft製品との連携まあ、
228:43 これらを主に見ていきます。で、サードパーティ製品の連携についてはですね、これはもう。
228:50 参考程度にとどめます。ではセキュリティコパイロットの概要です。 ではイラストを見ていきましょう。このイラストではですね、左側、これがあのAI、
229:03 まあアンドロイドくんですね。で、右側が人間だという状態ですが、 この左側のアンドロイドがですね、まあ、事件の状況整理、それから分析を行っています。
229:16 発見された証拠の情報をまとめてですね。
229:19 そこからわかることだったり、あるいはまあ、仮説の提示とかを行ってくれています。 そして右側のまあ、ガタイのいい刑事はですね、まあ、その内容を参考にして、
229:31 まあ自身の判断で、まあ何らかの行動を取ろうとしています。なんでまあAIがですね、 これは良き相棒のような感じが出てるんじゃないかなと思います。で、
229:40 セキュリティコパイロットをうまく使う場合はですね、この共同体制、 どう構築しますかという点がポイントになってきます。
229:54 まあ、このセキュリティコパイブとまあ、より端的にですね、この役割表現しますと、 まあ、AIによるセックオプス支援という言葉が当てはまるんじゃないかなと思います。
230:07 で、図で全体像を眺めておきましょう。 様々な場所から発生するまあシグナルですね。これはログという形で、
230:16 まあセンチネルに集約されていきます。
230:20 で、セキュリティコパイロットはそこから情報を抽出して、その要約、 あるいはまあ洞察も添えて担当者に渡します。まあ、こういう流れを作るということですね。
230:32 あ、あとセキュリティコパイロットについてなんですが、これはまあ簡単に言うと、 まあ、オープンエーアイのエルエム。これにまあ、
230:43 膨大なセキュリティインテリジェンスの情報も手間。
230:47 そうですね、まあチューニングしたみたいなものかと捉えればいいかと思います。そして、 セキュリティコンパイロットのビジネス価値について、
230:57 これもごく簡単に整理をしておきたいと思います。基本はですね 運用効率とか分析精度の向上、そしてまあそれによりもたらされる、まあ、
231:08 インシデント対応のまあ時間削減ですね。mean time to repair。
231:14 としてますが、まあ時間の削減があ、主な価値かと思います。まあ、多様なデータソースを、 まあ的確に参照して分析してレポーティングまで進められるというものですね。
231:25 まあ基本的な分析であれば、もうエーアイに素早く行ってもらって、 まあ人はより高度な洞察であったり、
231:32 あるいはまあ判断にまあ時間を割くということができるようになると、 まあそれが期待されるということになります。
231:42 で、まあ、フォレスター社のリポートを見ても、まあこういった形で、 まあ非常に好意的な数字が紹介されております。そしてもう一つ、
231:52 注目しておきたいのが、まあ人材育成への貢献ですね。 人材育成への貢献このフォレスター社のまあレポートにおいても、まあ、
232:00 ジュニアスタッフのスキル向上に役立つねという回答が結構ありました。 とまあ特にですねある問題に対してどういう分析をすればいいか、
232:10 どういうアクションをとるべきか。
232:13 まあこれをAIの場合は、まあ根拠を添えて説明をしてくれるので、 まあジュニアスタッフにとってはそうした情報が何より勉強になるんですねえ。
232:22 まあ特にですね。 まあAIとかDXとかでまあ人材不足ですねとまあよく言われるんですけども、
232:27 その陰に隠れてセキュリティ分野の人材もすごく不足してますねと言われてます。なので、 まあセキュリティ管理面、この人材不足を一致しいとされているんですが、
232:37 その人材育成の貢献というものも長期的に見たら効果が期待で。き。る部分かと
232:42 思われます。そして、scuによる課金モデル、これも見ておきましょう。 これはですね。まあ、AIベースの、まあサービスらしい料金体系となっているので、
232:55 これは注意が必要です。まあ、基本は、まあ、従量課金制といえば、 まあそうなんですけれども、まあ、リソースの稼働時間というよりは、まあ、
233:07 消費した計算リソースに基づくような、課金体系です。
233:12 なので、まあ、レスポンスタイムは仮に同じであったとしても、まあ、 複雑なクエリを処理しましたという場合は、
233:21 まあより多くのSCを消費するということになります。で、scuですね。 これはあの2種類ありますので、こちら見ておくと良いかと思います。
233:31 プロビジョニング済みのscu、それから、超過分のscuですね。
233:37 まあ、基本は消費量を予測して、まあプロビジョニング済み、 scuこれを用いることになります。ただですね、インシテントが発生しました、
233:46 という時に、その対応で、まあ一時的に、まあ、 大量の分析をAIとともに行うというケースはやはりありえます。
233:53 その場合はオンデマンドで、まあ、超過分のscu、消費するということがあります。 まあ、ちょっとだけ高くなるということですね。
234:05 え、これら、scuによる、まあ料金台形、これはまあ、 油断するとすぐに使用量が増えてしまうんですね。なので、まあ、
234:12 ダッシュボードを使ってチェックしたりとか、あるいはまあ、 アラートも設定することができますんで、まあ、
234:18 コストがあんまり増えすぎないように注意しつつ運用することが望ましいです。で、 場合によっては、まあ、こういったものを使って、確認して、
234:26 ここコストちょっとかかりすぎやなというのがあれば、ケーエスシーユーの計画、 これを最適。化。して、対応をしましょう
234:34 生成AIベースの課金モデルですね。ここはあの注意が必要です。というわけで、 本節のまとめです。生成AI系サービスとしての側面を確認して、
234:46 利点や注意点見てまいりました。では、 セキュリティコパイロットの機能とユースケースこれを見ていきましょう。
234:56 ではイラストですね。イラストでは、あの冒頭に出てきたあのガタイのいいケージですね。
235:04 彼がまあAIの働き分に感心しているという様子が描かれています。まあ特にですね、 あの多様なリソースと連携させて使うことで、
235:14 まあAIが持つ豊富な専門知識というのが生かされるようになります。ここではですね、 その活用シナリオを見ていこうと思います。まずですね、インシデント対応の迅速化、
235:27 この例ではまあ、あのオペレーション担当者がですね。
235:31 自分に対応をアサインされたインシデントの要約を指示しています。 ちょっとこれ画面では見えにくいかもしれませんが、この右側の図ではですね、えっと、
235:40 最新私に割り当てられたアクティブなディフェンダーインシデントなんですか？ という質問がここで書かれております。まあ、仕事を始めるにあたって
235:49 自分の仕事は何ですか？というふうに要約してくれと言っているわけですね。そうすると、 まあ、結果としてこういうインシデントが安定にアサイン。さ。れ。て。
235:58 ますとようやく結果が出てきます
236:01 で、まあ、ちょっと頭いいなと思ったのは、これようやくを単に出すだけじゃなくて、 まあこういう状況であるから、
236:08 あなたが今こういうことするといいかもしれませんねっていう、まあ、 推奨策もまあ時に出してくれることがあるんですね。担当者が今何をするべきで、
236:17 じゃあそれをどう達成できますかというのを、まあ、 素早く情報を得られるということになります。そして、高度な分析や調査、支援、
236:25 こういったユースケースもあります。
236:28 例えばですね、分析の方針を提示すると、まあ、その内容に沿ったケーキウェルクエリ、 これを構成してくれます。まあ、ケーキウェルクエリ、これもまあ一応クエリなので、
236:36 コードを書かなきゃいけないんですけれども、まあ代わりに AIがそのコードを書くということができるようになるというわけですね。まあ、
236:44 ケーキウェルクエリとか、ああいった思って、まあまあ、エスキューエルもそうですけど、 クエリは行動ですから、まあ、少し学習のコストがかかってくるものではある。んですけど。
236:53 もまあ、 AIに指示すればまあそこまで詳しくなくても目的に沿ったものが作れるということになります。
236:59 で、さらに優しいのはですね、 優しいポイントはケーキをやるクエリ構成してくれるんですけども、その実行した結果、
237:06 まあそれを実行してくれるし、 その実行結果の要約も合わせて行ってくれるということですね。
237:12 もうまさにもう何でも必要なこと全部やってくれるというようなことが言えます。で、 あと他にもですね、えっと、複雑な分析が必要そうだという場合に役立つ機能があります。
237:24 例えばですね、ウェブサーバーに悪意あるスクリプトが送り込まれましたという、 まあインシデントがあったとします。で、そのスクリプトを解読してですね、
237:33 つまりこれは何をやろうとしたんやとの分析しなきゃいけないんですけれども、そういった、 サーバーに送り込まれたスクリプトって、あのだいたい難読化されているんですね。
237:42 私もずっとずっと昔のインシデント対応した時に難読化されていてですね、 これつまり何がやりたいんやっていうのが、もう。読む。
237:49 のにめちゃくちゃ時間がかかったということがあります
237:52 大変なんですけれども、それ、 AIの力を借りてスピーディーにコード内容を読み解くことでも、あ、
237:59 こういうことをやりたかったんだじゃあ次こういうアクション取ればいいなということがわかるようになります。分析調査支援、まあ、非常に役立つ機能ですね。そして分析結果、ここまで進めてきましたんで、分析してきましたんで、結果がまとまってきたらレポートを作成します。で、このレポート作成でもセキュリティコーパイロット支援してくれますはい、もう。本。当に何でもやってくれます。ね、
238:22 まあ、基本的にはあのレポートの作成を指示すればオーケーなんですけれども、ただまあ、 この時に一応注意点がいくつかあります。まあ、これはまあ、
238:32 あの一般的な生成AIのプロンプトエンジニアリングの話にはなるんですけども、まあ、 できるだけ、レポートの主題を、ああはい明確に指示することが望ましいんです。
238:42 まあ、何の情報にフォーカスするか、 これは人が判断すべき部分であるということなんですね。まあ、この点にだけ注意した上で、
238:50 まあ、レポート生成。
238:52 維持すると、まあこういう形でまとめますというのが出力されてまいります。その後、 まあレポートを生成したら、まあ生成して終わりじゃなくて、
239:01 まあ一応まあ他の人に共有したいので、 まあその場合はまあピン留めの機能があるようですんで、
239:07 まあピン留めするなどして他の人が後から見やすいようにしておくと良いかなと思います。
239:16 で、ここまで一連の流れ紹介してきましたけれども、まあ、 こうしたステップをまとめたプロンプト集として、
239:23 まあプロンプトブックというものも用意されています。それはですね、 まあMicrosoftが用意したものも使えるんですが、
239:30 まあ組織の側で独自にまとめたプロンプトブック、 これも用意して使えるということになります。で、すんで、まあ、
239:37 プロンプトブックを使って、まあ定型化された分析っていうのは、 まあある程度自動化ができるということになり。ます
239:46 まあここにまあ、プロミプトブックの例というのがまあありますね。これもまあ、 ぜひ参考にしてみてください。では、
239:53 マルチテナント道具の機能についても紹介しておきます。まあ、この機能はですね、 端的にはまあ自身、自身の属するテナント以外でも招待されたら、
240:03 そこでセキュリティコーパレルを使いますよというものですね。これ、 何が嬉しいかなんですけれども、まあ企業は必ずしもですね、十分なセキュリティ対応人材、
240:12 いつでも揃えられるというわけではないんですね、
240:16 で、 こういった時にまあ外部の専門家招いてスムーズに対応開始できるということになります。
240:21 マルチテナント等はで、まあ実際にインシデント発生してしまったらですね。 もう対応は一刻を争うものになります。
240:28 そうした時にスムーズにオンボーディングしてスムーズに生成エアゲ 情報収集から対応まで専門家です。
240:34 進めてもらえられるようにするということは非常に重要です。
240:42 で、これ以降はまあ、Microsoft製品との連携について見ていきます。で、 まずはセンチネルですね。まあ、センチネルとの連携。これはまあ一番基本となるもので、
240:53 ほぼほぼ必須になる連携です。エミキの図ではですね、センチネル以外にも。まあ、 ディフェンダー、エックスディーアールとの情報、連携ですね。
241:02 連携した上で情報を参照できるように構成されています。
241:06 まあ、とにかくですね、もう多様なデータをセンチのようにまず集約しておきましょうと、 その上でCopilotがそれを参照できるようにする。まあこれがまあ、
241:17 王道パターンの一つなのかなと思います。そしてエントラID連携ですね。まあ、 エントラIDについては、これはあのまあサインインに関するアラートであるとか、
241:29 こういったものは基本的にあのセンチネルの方にまあ一応吸い上げられているはずではあります。
241:36 あ、だったらなんでエントラ、IEとも連携するんだという話になってくるんですけれども、 それはですね、えっとまあ、アラートの情報とか、
241:44 まあ確かにセンチネンの方に入ってきてはいるんですけれども、ただ、その場合、 そのアラートを発生させたルールって何なんだ、ちょっと詳しく教えてくれというのを、
241:53 まあ、セキュリティコーパイル、まあ、疑問を持つわけですね。 その場合に参照できるように、ちょっと今、現状を教えてよということはまあ、
242:01 参照できるようにするという。ことですね。
242:05 なんでまあ、 より詳しい文脈を踏まえた対応が必要という場合はCopilot使用できますということですね。そしてパービュー連携パービューはえっと、こちらの講座では取り扱ってきてはいなかったんですけれども、パービューはですねえ、ガバナンス関連のソリューションです。ガバナンス関連で、まあいろいろな使い方があるんですけれども、まあ例えば。
242:33 DLP、データロスプリベンションですね。この機能が代表的です。まあ、 データの漏洩とかを起きてないかをチェックして、
242:41 場合によってはブロックするという機能なんですけれども、これ、 あのポリシーをレビューするという使い方がセキュリティコパイロットでも可能になります。
242:51 これはですね、まあ、あの問題発生時に対応するだけじゃなくて、定期的なレビューでも、 もう定期的なレビューでも役に立つということですね。
243:01 レビューにおいても問題も確認するというときに使えます。特にですね、 あの企業の規模が大きくなってくると、
243:08 こういったガバナンス上のチェックルールであったり、まあデータであったり、種別、 まあ種別が膨大になってしまってで、もうルールも多くて複雑で、
243:17 もうわけわからんということになってしまうことがあります。で、 こういった抜け漏れの有無も、まあこういったAIの力を使うと、まあ、
243:25 効率効率的で網羅的にできるようになるという効果が期待できます。
243:32 ですんで、まあ、インシデント対応とかそういったイメージが強いんですけれども、 管理という観点でも使いどころがあるんだなということで、
243:41 まあインスピレーション得ていただければいいかなと思います。そしてえ、 インチューン連携ですね。インチューンこれは
243:49 デバイス管理系のソリューションですね。まあ、よくある例として、 まあエンドポイントの比較分析、これが挙げられます。
243:57 まあ同じ構成をとっているはずの、まあ複数のデバイスがあるとしまして、 まあそのうちの1台で問題が発生しました。で、こういった場合、
244:05 セキュリティコパイロットはまあうまく情報を出してやると。まあ、 構成を比較して分析することで、まあ問題発生の原因何かなというのを分析、
244:14 でしてくれるということですね。本来ならえ、違いがないはずなのに、 なんか違いがあるなと。それがもしかしたらエラーの原因かもしれないなというのを、まあ、
244:24 ？
244:24 AI側でまあちゃんと分析をしてくれるということが期待されますそれではですね。 本節のまとめですセキュリティCopilotニュースケースを
244:35 いくつか見てきました。まあここで紹介した以外でですね。 まあアイデア次第でまあ様々に利用できる余地があるかなと思いますんで。ただまあ、
244:44 あのコストには気をつけつつ、ではあるんですけれども、 有効に使っていけるかなと思います。まあいろんなアイディアがありますんで。
244:53 参考に今までのユースケース参考にして使ってみると良いかなと思います。では、 他製品。他のサードパーティ製品とセキュリティコパイロットの連携、
245:05 これはまあ参考情報ということで留めておきましょう。まあ、 サードパーティ製品の連携まあプラグインとして、
245:12 まあ主要なツールとの連携が可能ですということですね。 まあ特にサードパーティ製品長年使い続けてますという場合。
245:21 それらを移行するにはですね、結構重たい意思決定が必要な場合があるんですね。ただ、 それでもセキュリティコンパイロット使いたいなという場合、
245:30 まあこういった連携のパスも用意されていますので、 まあプラグインという形で用意されていますんで、
245:38 まあこれらも参考にしていただくとよいのかなと思います。では、本章のまとめです。 本章ではセキュリティコンパイロットについて見てきました。
245:49 まあ、セキュリティコパイロットですね。まあ、いろんなところで使える、 まあセキュリティオペレーションに使えるというソリューションなんですけれども、ただ、
245:57 scuベースこれ、生成がベースですね。 この料金体系には注意しましょうという点を見てきました。それから、
246:03 セキュリティコパイロット、主要機能ですね。 セキュリティコパイロットにオペレーション迅速化であったりとか、
246:09 あるいは他のMicrosoft製品との連携についてしてきました。それから、？ セ。キ。ュリティコパイロットと他製品の連携これはもう参考情報ですね。
246:17 サードパーティー製品との連携も一応可能なんですよ、ということを見てきました。まあ、 とにかくですね。有効に使えば、まあかつアイデア通りに使っていけば、
246:26 もう迅速的確にいろんなセキュリティオペレーションできますよというツールですね。 極めて強力なツールです。ぜひ参考にしていただければと思います。
246:40 はい、それではですね、15時十分となりましたので、 トレーニング再開していきたいと思います。画面の向こう側にいらっしゃる皆さん、
246:48 お戻りいただければと思います。はい、本日ですね、 9時30分からスタートしました今回のトレーニングでございますが、ご前頭、
246:56 今までいかがだったでしょうか？インフラストラクチャーとですね、 クラウドセキュリティの方をしっかり学んでいたかなと思います。
247:04 まあ改めて、あのアジェルというものは非常に多岐にわたる、 まあサービスを出しているなということが、あの改めて落ちも感じました。あ、
247:12 そういったですね。様々な重要な技術、そしてサービスがあり、 それをこう連携させていってですね、まあ今後のデータ活用、そしてAI活用というものを、
247:21 まあ進めていくというのが、これから求めてくれる、 求められるのかなということを改めて私も感じました。今回のトレーニングですね。
247:29 最後のセッションでございます。データベースで。す。こちらですね、
247:33 はい、時間としましては、2時間となっております。 15時十分から17時十分までですね。2時間を予定しております。
247:41 途中ですね、16時十分から16時20分は休憩ということになっております。まあ、 ここはですね、しっかりこうリフレッシュをいただければと思います。はい、
247:50 今回の集中講座ですね。まあ、もう一人というところで皆さん頑張っていきましょう。
247:56 では、 データベース講座適材テキストなデータベース選択とデータ資産の利用に向けてというところで皆さん学んでいきましょう。画面の方はですね、序章の資料を出しております。
248:10 はい、ページめくりまして今、画面に映している序章の内容となりますが、 まあこの内容はですね、
248:16 インフラの講座とセキュリティの講座同様となります用語の確認の資料と、 本講座で紹介する主なサービスというページがございます。こちらはですね、
248:26 各自ご自身でご覧いただければと思っております。 私の方からはまず本講座の概要ですね、
248:33 説明をしていきたいと思っておりますこの講座を受講すると、 一体どのような知識が得られるのでしょうか。
248:41 目次ですはい。今回ですね。まあ皆さん、 Azureのデータベースの提案をお客様にしていくというのが皆さんの最終的なゴールかと思います。そのために、まずですね、データベースおよびその周辺事項に関して、基礎的な内容からスタートしていきましょう。基礎を固めた上で、データベースの二大カテゴリであるリレーショナルデータベースサービス、そしてノーSQLサービス、これらのAzure製品について学習をしていきましょう。
249:09 その後、お客様に提案するソリューションという観点ではですね、 データベースアーキテクチャ。これも大事かと思います。その後、
249:17 先ほども学びましたが、ガバナンス、セキュリティ、コンプライアンス、これですね。 AI活用、データ活用の大前提の学習かと思いますが、これについて学び運用、
249:27 最後にオブジェクトオブジェクションハンドリング事例ということですね。 お客様とのコミュニケーションにおいて重要な内容について学習をしていきます。
249:37 今見てる教材資料ですね。 お客様にAzureのデータベースを提案するときに必要な知識を網羅しております。
249:44 今回の私の講座の説明の中ではですね、ポイントの部分に絞って説明をしていきます。では、 皆さんしっかり身につけていきましょう。まずはじめに、
249:55 このデータベース講座がですね、ターゲットとしている技術的な範囲をお伝えします。 こちらの図をご覧ください。はい、でかでかと図がありますが。
250:05 データを利活用するために存在するデータストアという技術がありますが、 これは大きくデータベースストレージに分かれます。またですね。
250:16 分析に特化した分析用のデータストアというものもありますね。 ストレージはデータ保存に重きを置いたデータストアになります。一方、
250:25 データベースというのは、保存されたデータに対して、検索とか更新、 集計などを効率的に行う仕組みを提供するものです。
250:35 Azureには多種多様なデータストアサービスが提供されていますが、 この講座ではデータベースに焦点を当てていきます。皆さん、
250:43 データベースをしっかり学んでいきましょう。では早速とありますが、 資料の方を飛ばしまして、第一章のですね、学習からスタートしていきましょう。
250:52 この後、用語の確認のスライドからありますが、20ページほどですね。皆さん、 お手元で飛ばしていただければと思います。
251:01 はい、こちらですね。 第一章データを中心に据えたエコシステムの全体像というページこちら皆さん開いてください。こちらの章ではですね、データベースそのものについての基礎知識とデータベースを取り巻く事情について説明をしていきます。こちらの講座の目次です。まず最初にですね、現代のデータベースに求められる主要要件について学びます。
251:29 まあ、昨今のデータベースですと、もう単にデータを保存するというだけではなくてですね、 もう周りからいろいろ求められているんじゃないかなと思います。
251:39 続いてサービスモデルの種類です。こちらの言葉ですね。 皆さん見たこと聞いたことあると思いますが、改めて見ていきます。3つ目、
251:48 データベースの種類です。 rdbノーエスケールoltpoラップといったような用語について今一度復習をして、
251:55 最後にデータベース周辺サービスとの連携ですね。
251:58 はい、今回の章だとこちらの説がまあ一番大事な部分かなと考えております。 最初の三つの説はですね、まあある程度知ってるよという方も多いかなとは思いますので、
252:10 少し手短に進めていきます。はい。この章では全体感にですね、 こだわって学習していこうと思います。まあ、個別のAzureサービスというよりかは、
252:21 データベースとその周辺の関連領域を学んでいき。
252:25 データに関するエコシステム全体像を知ることを目的としていきます。 このあたりの知識がありますと、それぞれのデータベースの必要性だったり、
252:37 データベースを学んだシステムアーキテクチャといった内容はグッと理解しやすくなります。 では最初の説です。現在のデータベースに求められる主要権ですね。
252:49 改めて見ていきましょう。はい。
252:52 現代ではまあデータベースはですね、 まあ単に保存するだけじゃダメなんですよという話です。
252:58 もういろいろな要件があるかと思いますね。まあ例えばスケーラビリティとかですね、 柔軟性とか、まあ低レイテンシなど、まあこういった要件が様々あるかと思います。
253:08 まあそもそもなぜデータベースまあいろんな要件がですね。 まあ求められることになっているのでしょうか。
253:14 なんでこんなデブ数がなんか負担が多いのかと。皆さんいかがでしょうか。 なんかこういろんな理。由。が。
253:21 考えられるんじゃないかと思います。データベースに様々な要件がある理由ですね。 なんか思いつくものありますでしょうか。あ、この理由様々あると思いますが、
253:33 まあその一つとしてはですね、 まあ現代ではもうデータとかAIの利活用がもう半ば当たり前になっているからというのが一つ挙げられるかと思います。
253:45 まあ、現代のデータベースまあ、こちらのスライドにありますように。 まあ様々な背景からですね、いろいろな要件が求められています。AIの活用とか、
253:53 サービスのグローバル化というのはもう当たり前になってきておりまして。 データの種類とかですね。あと量もですね、もう爆発的にいろんなものが増えております。
254:03 まあ結果としてですね、データベースは。まあ、スケーラビリティとか柔軟性とか、 低レイテンシーといったような、まあ多様な能力というものをこう求めら。れ。
254:12 ているわけですね、
254:14 このようにどのような要件を上昇するかによって、 まあ選ぶべきデータスが変わってくるんですけども、はい、まあ、
254:20 このデータベースのですね、まあ、適切な選び方といったようなものとか、 まあ要件についてはこの後の章で学んでいきたいと思います。次のページにですね、
254:29 マイクロサービスというものですね、説明をしております。これ一つ、 技術トレンドとして今あるかなと思います。まあ詳細なところですね。まあ、
254:37 ぜひこのスライドを見ていただければと思いますが。まあ、非常に噛み砕いて言いますと まあ、データベースをちょっと贅沢に使いましょうね、という話ですね。まあ、 機能単位でデータベースを設けていきましょうよと。こういうふうに、こう機能単位ですね。
254:51 ちっちゃくアプリを作っていきますよと。まあ、これをしますと、 結果的にレスポンス速度が早まったり、保守運用がしやすくなったりするわけですね。
255:03 はい、今ですね、様々な。社会的背景とかですね。 技術トレンドについて少し話をしましたが、
255:10 こちらの表の方にデータベースに求められる使用要件をまとめています。まあ、 例えばスケーラビリティというものはシステムの拡張性に関する要件ですね。
255:20 他にもですね、柔軟性とか低レイテンシーなどありますが、まあ、 これらの細かい説明はですね。ぜひ皆さん、お手元のこちらを見て
255:29 振り返ってください。。
255:32 人によってですね、今後のショーの学習の中で、私が口頭で一緒に説明をしていきます。 はい、簡単ではございますが、こちらの説はですね、
255:41 これで終了ということにしたいと思います。 データベースには様々な要件が今あるんだよと。で、要件に応じてですね、
255:50 選択すべきデータベースは変わっていきます。個別のアジル製品に関しては、 この後の二章とか三章のところで学んでいきます。
256:01 では続いてですね、サービスモデルの種類について少し見ていきたいと思います。 こちらもある意味お馴染みかと思いますが、まあサースパースアイアースという言葉ですね。
256:11 まあ、これらの言葉の意味の違い、皆さん説明できますでしょうか。まあ、 違いはなんだったっけなとなってしまうと、ちょっと困ってしまうかと思います。
256:21 これらサースパースアイアーズですが、お客様側とAzure側での事業、 責任範囲について区別することが重要ですね。
256:31 これら三つは、Azureが提供しているサービスの提供形態の事業になり、 違いになります。アイアースはインフラを、パースは開発実行環境を、
256:43 そしてサースは完成したソフトウェアを提供する形態でした。 Azureの責任範囲というのは、アイアースパースサースの順番に広くなっていきます。
256:59 こちらサービスモデルをお客様に提案する時ですが、 まあ基本的にはどこまでをAzureに任せたいか、
257:06 どこまでを自身でコントロールしたいかという観点でですね、選んでいく必要があります。 基本的にはサースの方がまあ運用負荷が一番小さいですね。
257:15 もう提供されている範囲でお客様は使っていくということになります。 一方アイアスになってきますと、もう細かいところまでのチューニングができます。
257:24 インフラ構成を自分たちでもうギリッギリにチューニングしたいんだという場合だったら、 アイアスを提案するということになってきます。こちらのサービスモデルですが、
257:36 さまざまな観点がございます。これらを踏まえてですね、 お客様の方に適切なサービス形態を提供していく必要がございます。まあ、
257:45 やはり特に重要なのはですね、まあ、最初の運用不可のところかなと思います。 運用不可をどれほど下げたいかと。
257:53 まあもう少しこの、厳密に言うと、こう、コストの部分ですね。 運用不可でコストというものを、まあどれほど避けたいかと表現がまず大事かと思いますが、
258:02 まあそれと平行にですね、既存システムとの互換性の部分とか、 独自のカスタマイズ性をまあどれほど持っておきたいかといった部分ね。まあ、
258:10 コントロールカスタマイズ性といったところ、まあ、こういったところを、 まあ総合的に目指してバランスをとっていき、
258:17 お客様と一緒に検討していくというのが必要と。な。ってきます
258:22 はい、簡単ではございますが、アイアスパースサースというところですね。 振り返っていきました。こちらの説は以上の内容となります。パースはソフトウェアですよ。
258:33 パースはプラットフォームです。アイアスはインフラを提供します。 それぞれの特徴を踏まえてですね、
258:40 お客様が求めるサービス形態というものを提案していく必要がございます。
258:46 はい、ここまでの内容ですが、まあインフラの講座とかですね。 あのセキュリティの講座でも、まあ少し話は出てきたかなと思います。
258:55 ここからはよりデータベースに限った話をしていきたいと思います。 まずデータベースの種類です。データベースまあ、いろいろな種類があるかと思います。
259:06 まあ細かい観点で言いますとですね、もう何十個、何百個と、 もしかしたら種類があるかもしれません。
259:14 まず、データベースの大カテゴリとして抑えていただきたいものが二つあります。 それがかの有名なアールディービー、そしてノーエスケールとなります。
259:27 アールディービーは構造化データを扱うことに長けたデータベースです。 一方ノーエスケールは非構造化データ反構造化データを扱うことに長けたデータベースになっています。まず。
259:42 扱えるデータの種類がこの二つだと違うんだというところをですね、 押さえていただければ大丈夫です。こちらにrdbとノーエスケールですね、
259:51 違いの部分を表でまとめています。細かいところはぜひこの後ですね、 あの講義終わった後とかに見ていただければと思いますが、
259:59 まあデータモデルの部分がまず違うんですよというところですね。 rdbですと基本的にはテーブルという構造がデータには必要なんですけども、
260:09 まあノーエスケールですとより柔軟になります。
260:12 まあ、ドキュメントとかですね。キーバリューといったような形で、 まあ様々な種類の構造に対応するんですよということです。で、
260:20 こういったデータの構造の違いですね。データモデルの違いのところからですね。まあ、 一貫性とかスケーリングのところにも違いが発生してきますし。結果、
260:30 利用シーンというものも異なっていきます。詳しいところはですね、 二章とか三層のところでまた説明をしたいと思います。
260:40 で、今話したのはですね、データの構造という観点で、 まあデータベースの種類は違うんですよという話だったんですけども。まあ、
260:49 データの処理という観点でも利用されるデータベース利用される製品というものをカテゴライズすることが可能です。それがこちらのoltpとorapですね。oltpはリアルタイムなデータ処理のことでした。この処理を支えるためにはですね、基本的には低レイテンシー、そして高可用性というものが一般的には求められます。
261:11 一方右側のですね、オーラップ。こちらはオンラインの分析処理、まあ、 過去のデータを分析しましょうというような処理のことをこのオーラップというふうに呼んでおります。まあ、この分析の部分はですね、はい、MicrosoftもしくはAzureの糧です。サービスのカテゴリーでしたら、例えばMicrosoft、ファブリックなどのですね、まあ、分析プラットフォームのようなものがになっております。今回のデータベースの講座ですが、こちらの。
261:38 Oltpのシステムですね。 主にアプリケーションを支えていくようなoltp系のデータベースに焦点を当てて、
261:46 今後学習を進めていきたいと思います。で、ここでですね、 一つお参考情報というところでですね、こちらの用語ですね。ぜひ知っておいてください。
261:56 ポリグロットパーシステンスというものです。データの構造、データの処理の内容、 まあ様々なワークロードがあります。そのワークロードに応じて。
262:07 最適なデータベースを組み合わせていこうよという考え方がですね、 このポリグロットパーシステンスとなります。まあ、
262:14 かつてはなかなか難しかったんですけども、まあ、 昨今のクラウド発展に後押しされてですね、
262:19 こういったところまでできるようになっています。はい、以上でですね、本稿 本節の内容は終了となります。まずデータベースとして、
262:27 アールディービーとNosケールこの二つがあったなというところを思い出していただければオッケーでございます。
262:35 では第一章ですね。まあ導入の部分ですが、 最後にデータベースの周辺連携の部分についてですね、学んでいきたいと思います。。
262:43 どのサービスで使えばデータの価値を上げられるのかなというふうに悩むことがあるんじゃないかと思います。やっぱりデータベース単体だけだと価値の最大化というのは難しいですね。まあ、周辺サービスと連携するというのが大事になります。まあ、ここの連携するというところがですね、大事な考え方ですね。
263:03 まあ、データベースというものがまず中心にあるんですけども、まあその証言にですね、 データの活用をするための分析系のサービスもありますし、
263:12 安心安全にデータを利用するためのガバナンス、セキュリティ、 コンプライスといったサービスもあります。こういったサービスと連携して、
263:21 いわゆるこうエコシステムのような形ですね。こう、生態系を作っていっていくことで、 こうデータの価値というものが最大化されるわけです。
263:32 え、こちらのデータガバナンス、セキュリティコンプライアンス。 こちらは先ほどのセキュリティのですね、口座のところでお話がありました。
263:40 まずデータガバナンス。これをしっかりしていきたいとなりましたら、 Microsoftパワービューというサービスがございましたね。
263:48 データベースと連携することによって、 組織のルールとかポリシーに則った適切なデータ利活動というのができるわけでした。
263:57 セキュリティのサービスもありました。これは大きく二つ学んだかと思います。 MicrosoftセンチネルとMicrosoft、ディフェンダー、
264:06 フォークラウドのようなサービスですね。 自社の中の重要な資産であるこうデータというもののセキュリティを守りましょう、
264:13 データの漏洩とか不正アクセスとか、 決してないようにしましょうというのがこれらのサービスになります。最後ですね。
264:20 コンプライアンスになりますが、これAzure policyになりますねはい。
264:26 まあ、放棄とか規制に準じてデータを管理するためには、 こういったAzure policyが必要となります。
264:32 これら三つのサービスとデータベースを連携させることによって、セキュリティ、 ガバナンスなどを、コンプライアンスなどをですね、ちゃんと守ることができるわけです。
264:41 これね、あの土台の部分はしっかりできたかなと思うんですけれども、 まあデータ利活用するってなってきますと、やっぱりこう、データがですね、
264:49 こうまとまってないとですね、扱いづらいです。
264:52 で、データまとめましょうという時には専用のサービスがありまして。まあ、 いわゆるetlとかですね。ELTと呼ばれるような操作になります。Azureですと、
265:02 AzureデータファクトリーとかAzureデータプリックスというようなサービスがですね、このデータ統合と呼ばれるような操作を行ってくれます。この二つのサービスサービスですね。しっかりこのデータ統合できるんだというところで結びつけて押さえておきましょう。データがですね。
265:20 統合されてきれいに一箇所にまとまりました。 そしたらやっぱり活用していかないわけにはいきませんので、
265:27 Microsoft power platformとかですね。 アージュドマシンラーニングと呼ばれるようなサービスを使ってデータ活用を進めていきましょう。分析をするということもできます。
265:39 少し名前がありましたが、Microsoftパフリックとかですね。 こういったサービス使えば、データの分析を進めることができます。データ分析しますと、
265:49 まあ、データドリブンで意思決定をしたりですね。 データを活用したような新しい事業創出につながってくるかなと思います。はい、
265:57 以上がですね。この説の内容でございました。まあ、端的に言うと、 データベース単体ではなくて、連携をすることですね。
266:04 データの価値というものを最大化することができるんだよ。と。い。う話でした
266:11 以上で、本書の内容は終了となります。まあ、 捨てた内容も多かったかもしれませんがですね。まあ、
266:18 基本のところをこの章ではまずおさらいして、 じゃああの専門的なところにこの後入っていきましょうというふうに進めていきたいと思います。本書の内容は以上となります。ではいよいよですね。第二章から。
266:32 Azureに関わってくるような話ですね。やっていきましょう。第二条、 Azureのリレーショナルデータベースサービス外観というところです。第二章では、
266:43 Azureのリレーショナルデータベースサービスアールディービーについてですね、 しっかり学んでいきたいと思います。四つ説がありまして、まあ最初の部分はですね、
266:55 Azureのアールディービーの概要とか。
266:58 機能要件非機能要件と呼ばれるものまあ、少し複数に相当する部分もありますし。 後半からですね。Azureのrdbのですね。
267:07 サービスサービスの説明をしていきたいと思います。 今回の賞の学習を通じましてですね。
267:14 Azureが提供する多様なアールディービーサービスの特徴や機能利用シナリオをしっかりご自身の言葉で説明できるようになっていきましょう。
267:26 では最初の節に入ります、rdbの概要をですね、改めて見ていきたいと思います。まあ、 rdbと言えましたら、構造化されたテーブルは使うものですと、うん、
267:37 rdbはどんなデータベースっていうふうにですね言われたらですね、 きちんとご説明できるようになっていただければと思います。
267:46 左下の図を見てください。rdbでテーブルを管理しておりますが、まあ、 rdbですとこのテーブルのキーというものが大事なんですね。
267:56 このキーというもので、テーブル同士は関連付けるということをしています。まあ、 この関連付けの管理というものが、アールディービーは非常に得意でして、
268:05 まあこれによってですね、 テーブルの各行に対応するようなレコードの重複とか矛盾というのが発生しにくくなると。
268:13 で、この性質がやはり顧客管理システムとか在庫管理システムとか、 業務においてはもう非常に重宝されるわけです。
268:23 先ほど説明した通りね レコードの重複とか矛盾が発生しにくいというのがまずRdの特徴の一つです。
268:30 データの整合性、一貫性と呼ばれるものですね。で、こういった性質を持ってますので、 まあ、テーブルデータでしたら、やっぱりrdbで一元管理したくなります。で、
268:40 rdbというのはまあデータを管理する機能をですね、もう豊富に持っておりますので、 アクセス権限とかですね。まあ、柔軟にすることができます。
268:49 まあデータベースの種類にもよりますが、まあテーブル単位だけではなく、 列単位のデータアクセス権限設定とかもですね。
268:56 まあ昨今普通にできるようになっております。一つ、注意点となりますが、 アールディービースケーラビリティですね。拡張性に関しては、
269:05 基本的には垂直スケーリングになります。 CPUとかメモリなどの物理的な装置を強化していくというのが、
269:12 アールティービーの基本的なスケジューリングのスケーリングの戦略になります。
269:17 この観点から、物理的な限界があるという部分と、 あとコストの高額になってしまうというところがrdbのスケーラビリティに関しては一つ注意点となります。これはですね、押さえておきましょう。はい、以上ですね。こちらの説の内容は終了となります。rdbというものはデータの重複とかですね、矛盾というものを防ぐことができる、業務で使いやすいデータベースなのだということを改めて振り返っていきました。
269:48 では2つ目の説に入りましょう。ここまではですね、割とこう基本的な内容ではありますが、 機能要件、そして非機能要件という標語についてですね、振り返りましょう。
270:01 こちら二つの言葉ですね。しっかりこう区別できますでしょうか。 機能要件これは何だったかと言いますと、
270:10 システムとかソフトウェアが何をするのかというもの。
270:14 定義したものでしたね。これはユーザー目線で言いますと、 まあ何ができるのかというものを考えたものと言い換えることができます。まあ、
270:25 例えばイーシーサイトでしたら、 ユーザーは商品を検索できるというものは機能要件になります。一方、
270:33 この機能要件以外のことですね。 システムの動作以外の要件は非機能要件というふうに呼ばれます。
270:41 様々なものがあります。
270:44 一般的には、品質に関連するような要求のことが非機能要件となります。 いつでも安心してサービスを使うことができるかという可用性。
270:54 将来のアクセス増加にも耐えられるかという拡張性ですね。まあ、 こういった部分が一般的な非機能要件になります。
271:02 オンプレからクラウドへの移行という観点でしたら、やはりこの移行性という部分はですね、 かなり大事な部分になるかと思います。
271:13 システム導入というものの、まあ成功をさせるためにはですね、 機能要件以外の非機能要件の部分にもこうしっかり注意を配らなければなりません。
271:24 本日の内容は以上となります。機能要件と非機能要件のところをですね、 復習していきました。ではここからですね。いよいよ、
271:34 このAzureのrdbサービスの概要の部分ですね。学んでいきたいと思います。 たくさん。
271:41 種類があるかと思います。皆さんどのようなものを思いつくでしょうかね いろいろ種類がありますが、まあちょっとずつですね機能とかですね。
271:51 違ってきますので、しっかり区別して押さえていきましょう。で、今回の講座ですが、 押さえていただきたいアールディービーサービス七つあります。おそらくですね。
272:02 お客様からも要望が多くて、 かつアジャイルとしても結構ウェイトを置いて重要なサービスだと思いますので、
272:09 しっかりですね。
272:11 これら押さえてください。あえてですね。 ここではサービス名のところ簡単に読み上げていきたいと思いますが、
272:17 Azureエスケールデータベースですね。で、 AzureエスケールマネージドインスタンスエスケールサーバーオンバチェラマシーでAzureデータベースフォーポストグレイスケールAzureコスモスデータベースフォーポストグレイスケール。
272:33 で、Azure databaseフォーマンSQL、 最後にOracle databaseアットAzureというこれらのサービスですね。
272:41 大事なrdbになります。この後の説明で、まあ、 ポイントの部分説明いたしますが、お時間ある時にですね、
272:47 こちらの表の内容はしっかり目を通していただければと思います。
272:52 まずこれらのサービスですが、利用しているデータベースエンジンにですね、 少し違いがありますねこちらの三つに関してはエスケールサーバーになりますし、
273:02 まあ、この部分はですね、この二つはああ、失礼します。こちらの二つはですね、まあ、 ポストグレースケールに対応しているものでございます。で、
273:10 こちらマイエースケールでこちらオラクルというものですね。まあ、 オンプレからクラウドへの一方性という観点だと、データベースエンジンの違いとい。う。
273:19 の。は大事になってきます
273:22 スケールアビリティのところ目を向けていきましょう。 基本的にrdbは垂直スケーリングという話をしましたが、
273:29 水平スケーリングの能力を備えているものがいくつかあります。 特にこのAzureエスケールデータベースですね。こちら大事な。
273:38 アールイービーのサービスとなっております。垂直スケーリング、 水泳スケーリング備えておりますで、アゼルコスモスディービーフォーポスト、
273:47 グレスケールも垂直スケーリング、水泳スケーリン。グ。と
273:50 え、二つのですねえ、機能を持っております。このスケーリングに関しては、 個々のサービスで少しで差異があることは押さえておきましょう。で、
273:59 セキュリティに関してですね、最後お伝えいたしますと、 このエスケールサーバーベースのこれら三つですね。これらはセキュリティに関してあ、
274:08 リッチな機能を持っております。データデータの常時暗号化とか、 データベースレベルの暗号化とかできます。
274:16 まあ、一般的なですね。まあ、通信の暗号化とかアイピー制限とかは、まあ、 すべてのデータベースで共通で可能です
274:24 これらAzureアールディービーサービスですが、非機能要件に関してですね 代表的な機能、こちらの表でまとめておりますので、ぜひご覧ください。
274:34 見たことない機能がですね、ありましたらぜひ詳しく調べていただければと思います。 こちらのハイバースケールというサービスレベルなんですけど、こちら大事です。
274:45 Azure SQL databaseのサービスレベルになります。こちらですね、 非常に大規模なデータを扱うためのものでして、まあ非常にスケールアップが柔軟で、
274:55 かつ高速になります。 読み取り用の水平スケールも非常に得意なアーキテクチャになっておりまして、
275:02 読み取り専用のレプリカというものを追加していって、 読み取り性能をどんどん向上させるといったようなことができます。あと、
275:10 このハイパースケールのサービスレベルですと。
275:13 原理的にはですね、こう、ストレージのあの上限設定っていうものがないんですね。 もう極めて大規模な、もう数百テラバイトとか、
275:20 そういった規模感まで拡張することができます。で、このハイパースケールですとまあ、 極めつけなんですけど、このバックアップ機能とかも非常にこう、優れています。
275:29 バックアップと復旧の部分が高速にできます。 このあたりはハイパースケールのアーキテクチャの部分が非常にこう工夫されているから実現されているものです。
275:41 まあこちらファイバースケールですね。大事な機能ですので押さえておきましょう。 で、この例で見るようですね。このAzureエスケールデータベースというものは、まあ、
275:52 ワークロードに合わせた柔軟性というものが非常に魅力的なんですけども、 その柔軟性というものはサービスの支払い方法、
275:59 まあ課金モデルというところにも関わってきております。 Azureエスケールデータベースですか？まあ、課金モデルが大きく分けて二つあります。
276:08 ディーティー。ユーベ。ースとブイコアベースですね。
276:11 まず左側dtuベースというものですが、 CPUとかメモリといった性能をdtuという一つのパッケージにしたものです。まあ、
276:20 なんか車のグレードをですね、まあ選ぶような感じですね。まあ、 手軽にこう性能を選ぶことができます。一方右側のvコアベースですと、
276:28 まあCPUとかコア数ですね。メモリ、 ストレージといったリソースをまあそれぞれ個別に指定できる柔軟性の高いモデルになります。
276:39 まあシンプルで、まあ構成のわかりやすさというものだったら、 まあdtuベースになるんですけども、まあきめ細かいですね。まあコスト最適とか、
276:49 まあ将来の拡張性を重視するんだったら、まあブイコアベースの、 まあ課金モデルの方がまあお客様としては使いやすいかなというふうに思います。
276:58 これ二つですね、課金モデルがあるということをですね、押さえていただければと思います。 では、本日の最後となりますが、
277:05 Azureのrdbサービス選択の観点一例を示していきます。
277:11 まず使用するデータベースエンジンの観点ですね。まあ、 これでこう使い分けがあるかと思います。まあ、マイエースケールとかオラクルをですね、
277:18 クラウド上でも使いたいんだと。 オープンプレーから移行を検討しているんだという場合でしたら、
277:23 Azure databaseフォーマイエースケールとか、 オラクルデータベースアットAzureといったようなサービスが候補として挙がります。
277:31 こちら大事なポイントです。
277:33 SQL Serverを使いたいという場合なんですが、 サービスの理由形態がファーストアイアスって2種類あります。**、
277:40 *れ大事なポイントです。パース型とサース型、二つあるんですよということですね。 パースタイプのSQL Serverを使う場合には、
277:48 Azure SQLデータベースとAzure SQLマネージドインスタンス、 この二つから選択することになります。
277:56 オンプレミスのSQL Serverと近い使用感を求めている場合でしたら、 こちらのAzureSQLマネージトインスタンスの方がまあよりこう近いかなと思います。
278:06 まあ一方ですね。Azure SQLデータベースの方だったら、 こうデータベース単位で提供されるので、
278:13 まあ例えばクラウド上で新規にアプリケーションを作りたいんだよねという場合だったら、 こちらAzureSQインターフェースがかなり使いやすいものがあります。 アイアスの場合ですね。エスケールサーバーオンバーチャルマシンとなりますが、 これはあのAzureの仮想マシンにAzureエスケールサーバー、
278:32 こうインストールするタイプですね。まあ、 仮想マシンのこの構成の部分から自由に調整することができますはい、
278:39 ポストグレーエスケール使っている場合で、 まあ例えばこう水平スケーリングが必要か不要かでですね。まあ、こちらのサービス、
278:46 使い分けが決まってきます。エスエスケーリング必要なんだよね。と。
278:50 大規模に伝えんだよねという場合だったら、 AzureコスモスDBフォーポストグレイエスケールというのが非常に良いサービスとなります。はい、こちらですね。Azureのアールディービーサービス選択の観点の一例となります。以上で、こちらの説の内容は終了となります。アールディービーサービスですね。様々ありましたが、それらの概要のところおよび使い分けのところを説明をしていきました。
279:20 では、本書最後の内容となります。Azureのrdbサービスの利用シナリオ、 これ学習をしていきましょう。まあ、
279:29 いろいろrdbサービスあるということがわかったんですけども、まあどんな時にですね。 まあ、どのサービスを使うとよいのかなという話をしていきます。こちら、
279:42 Azureの各rdbサービスが適する場面というのを表でまとめております。
279:50 まあ、先ほどの使い分けのところでもありましたが、まあ、データベースエンジンをですね。 ま、そこを基準に考えていただければと思います。
279:58 Azure SQLデータベースのというものは、 あの標準的にこう使いやすいデータベースになります。まあ、
280:04 最新のクラウドネイティブアプリケーションでは、 このAzure SQLデータベースがですね、非常にこう活用されると思います。
280:14 で、こちら。様々なですね、アールディービーがありますが、一つですね、 こう押さえていただきたいポイントがございまして、Azure SQデータベースですね。
280:24 あとこちらこのSQL Serverベースのものと、 Azure databaseフォーポストベースケールこの上の四つの部分なんですが、
280:32 このAI機能というものをですね、実は持っております。これ昨今ですね、こう、 追加されている新しい機能になるんですけども、やはりこう、ベクトル検索とかですね。
280:44 Azure AIと統合してですね、検索をするといったようなことが、 できるようになっております。やはりこうベクトル検索というものを使いますと、
280:52 こう意味ですね、データの意味を通じた検索とかに踏み込めます。まあ、さこれですと、 生成以外のこうラグというシステムとかがありますが、そういったところで、
281:01 あのスムーズに既存のrdbをこう拡張するような仕組みが整ってきているという部分になります。これは押さえていきましょう。
281:10 で、この後のページですが、 Azureのrdbサービスの利用シナリオに関して六つ用意しております。で、
281:17 今回はですね、丸一と丸二の部分を説明していきたいと思います。で、 残り四つの部分もまあよくあるですね、利用シナリオとなりますので、
281:26 ぜひ皆さんお目をですね、通していただければと思います。では、丸一番ですね、 水平スケールが必要な大規模データベースという話していきたいと思います。
281:38 はい、右側のですね。図を見て頂ければと思いますが、まあ、 グローバルな企業におきますとまあ、
281:44 数十テラバイトのデータというものを数千人規模で同時接続するといったようなワークロードありえます。で、そういった場合ですと、こう。障害発生時の復旧時間というものにも高い要求がある場合が多いです。関係者が多いからですね。
281:59 で、テラバイトレベルのデータ読み取りと高い復旧時間目標まあ、 この二つの要求にAzure scale
282:05 databaseのハイパースケールのサービスレベルというものが対応してくれます。 このハイパースケールによって、データ読み取りクエリの負荷というものを、他のですね、
282:16 あの読み取りレプリカというものにこう分散することができますので、高速にですね、 レスポンスを実現できるわけです。
282:25 で、ハイパースケールの復旧というのは高速だよという話をしましたが、これですね、こう、 データ量が多くなっても、もう数分以内とか、もうそういったレベルでですね、
282:34 復旧することができるんです。なので、 こういうグローバルな状況でスリーエイスケールというものが必要なんだよとなったら、
282:41 これ、Azure SQL databaseのハイパースケールサービスレベル、 これ非常に使えます。では、もう一つのシナリオですね、
282:49 エスケールサーバーアプリケーションの移行のシチュエーションです。
282:54 オンプレで稼働しているSQL ServerをAzureに移行したいんだよね、 という場合あるかと思います。
283:01 そのような場合はAzure SQLマネージドインスタンスですね。 これが便利になります。パース型で提供していますので、移行をしたら、
283:10 お客様はサーバーの運用からですね、解放されるんですね。
283:15 まあただ、お客様としては、まあ、 移行そのものにちょっと多少不安感を覚えることもあると思うんです。まあ、
283:21 移行したらシステムが動かなくなっちゃうんじゃないかなとか、まあ、 移行してる間サービスどうなるのかと。使えるのか使えないのかっていうところですね。
283:29 まあ、そこがちょっと気になるポイントかと思うんですが。まあその点、 Azureエスケールマネージトインスタンスは問題がありません。
283:36 まずこのサービスはエスケールサーバーとまあ高いですね。まあ。互。 換性を持っておりますので移行に伴うトラブルというのがあまり起こらないです
283:46 で、Azure databaseマイグレーションサービスというものと、 Azure data studioのこのAzure
283:53 SQLマイグレーション拡張機能というものを使いますと、 ダウンタウンダウンタイムを極めて小さくして移行することができたりします。
284:01 お客様のですね、こう、移行図の不安というものがなるべく小さくなるようなですね、 仕組みが整っているという部分、これは非常に良いポイントかと思いますので、
284:11 押さえておいてください。
284:13 はい、今二つシナリオを説明しました。他にもですね、丸三からですね。はい、 丸六という形で他のシナリオもありますので、ぜひこちらの方、学習しておいてください。
284:28 はい本書の内容は以上となりますね。 今回の説ではrdbサービスの利用シナリオについて学んでいきましたが、
284:38 この章ではまあ全体を通じて。
284:41 Rdbというところにですね、ご着目をしていきました。 アゼロのrdbサービス利用シナリアのところは本業のお客様への提案のところだからも使えるかと思いますので、しっかり学習をしていただければと思います。では以上で、第三章、第二章ですね、終了となります。rdbを押さえましたので、もう一つの大カテゴリーであります。ノーSQLの方、こちらの方、学習をしていきましょう。
285:15 第三章に入ります。第二章の方では、まあ、 データの整合性というものを重視するアールディービーについて学びましたが、
285:24 この章ではノーSQLです。まあ、どんな特徴があるのかなというところですね。 気になるポイントかと思います。まずノーエスケールの概要の部分を説明して、
285:34 Azureにおけるノーエスケールサービスの概要、そして最後に利用シナリオ、 この三つをこの章では学習をしていきます。
285:44 本書の学習を通じまして、 Azureが提供している多様なノーエスケールサービスの特徴や機能、
285:51 利用シナリオを理解していきましょう。では最初の説です、 ノーエスケールの概要の文から始めていきましょう。まあ、こちらはですね。
286:01 まあ皆さんご存知の内容もあれかと思いますので、 まあポイントの部分を絞って説明をしていきたいと思います。ノーエスケールですが、
286:10 まあどんなデータベースかと言いますと。
286:14 非常にデータ構造に対して、こう柔軟なデータベースなんですね。 まあテーブルという形ですね。
286:21 まあそれはもちろんこう対応しないわけではないんですけども、 テーブル以外のデータとかもうまく使うことができるんですよと。
286:29 こちらの図を見てください。
286:32 nosqはですね、 ジェイソンのようないわゆるドキュメントと呼ばれるような形式とか、
286:38 シンプルなキーと値のペアになっているキーバリュー形式といったような。 多種多様なですね。データモデルに対応するというのが一つ大きな特徴になります。
286:50 アールディービーの方では事前にスキーマと呼ばれるような、 まあ厳密なデータ構造を定義するんですが、
286:56 ノーエスケールではスキーマを変えることができたり、あとはスキーマをそもそも使わず、 スキーマ列でデータを扱うよりすることができるというのが特徴になります。
287:05 そしてもう一つですね。ノーエスケールのいいところなんですが、こちらです。 水平スケーリングがしやすいというものですね。
287:13 いわゆるこのサーディングという技術などを使ってですね。え。え？ 性能を向上させることができますよと
287:20 まあ、特にこの大規模なデータを使う現在のアプリケーションにおいては、 この推計スキリングという性質はとても貴重なものになります。こちらの表でですね、
287:31 ノーエスケールのデータモデルと対応しているOSケールサービスの表サービスをですね、表でまとめているものでございます。まあ、後ほどこちらもまた見ていただければと思いますが、例えばドキュメントというデータモデルでしたら、Azureでしたら。
287:49 AzureコスモスディービーフォーノーエスケールとかAzureコスモスディービーフォーモンゴディービーブイコアといったようなサービスがですね、対応しております。キーバリューの形式でしたらAzureコスモスディービーフォーテーブルもしくはAzureマネージドレディスですね。こういったサービスが対応しております。まあ、データモデルによってまあ得意なですね。ノーエスケールサービスありますので、ここの使い分けはしっかり。し。ていきましょう
288:18 では、ノイスケールですね。全体的なところを話しましたが、 まあ細かい特徴のところを見ていきましょう。まあ、こちら四つですね。
288:28 特徴を並べておりますが、まあ、まずRDBとの違いという観点でしたら、 データ整合性、一貫性の部分で特徴があります。
288:37 No、エースケールは基本的に可用性とかスケーラビリティを優先しますので、 整合性に関しては結果、整合性モデルと呼ばれるものをですね、採用することが一般的です。
288:48 まあこの結果整合性というものなんですけども、 まあエスエヌエスのまあいいねとかで考えると少しわかりやすいですね。まあ、
288:56 あのいいねボタンを押しますと、まあ、すぐに画面に反映されるわけなんですけども。
289:02 まあ、そのいいね押されたという情報が、まあいろんなこう、 サーバーとかにも広がっていきます。一瞬でほんの一瞬とかにはなるんですけども、
289:10 例えばこう東京で見たいいねの数とかと、まあ、 一時的に離れたニューヨークで見たいいねの数とかが、
289:16 まあ一瞬だけ違うといった時はあったりするんですね。
289:19 ただまあ時間を経ちますと、まあ最終的なまあいいねの数、 最終的な結果の部分はまあ一致するというもの。
289:25 まあこれはまあ結果整合性を表したものなんですけれども、まあ脳炎スキルとはいいのは、 まあ、こういった一瞬のデータのズレみたいなところは、
289:33 まあ一定問題ではないというふうに割り切って、まあ代わりに、まあ応答性の部分ですね。 まあ、
289:39 あと海王星の部分とかをあの重要視するというところを考えたデータベースになります。 まあ他にもこの脳Sキルです。が。まあ、分散思考であったりです。ね、
289:49 あとアクセス権限設定に関しても、まあデータベース単位とか、 まあコレクション単位でまあできますよという性質を持っております。まあ、
289:58 まずはあの結果、整合性のモデルであって、 あと水平スケーリングに向いてるんだよというところ、
290:05 ここをまず押さえていただければオッケーです。で、 先ほど説明したこの水平スケーリングなんですけれども、
290:11 まあシャーリングと呼ばれるような技術で実装していることが多いです。
290:17 まあ、サーディングというのは、まあ簡単に言いますと、まあ、 巨大なデータベースというものを、まあ、シャードと呼ばれる小さな断片に分解してですね、
290:28 複数のサーバで分散し、保存と処理をする技術のことを指しています。はい、 以上ですね。本節の内容は終了です。OSケールのですね。まあ、
290:38 概要などの全体感のところを見ていきました。
290:42 まあ、データ構造に関して柔軟性があって、 CAスケーリングが得意なんだよというのがノースケールになります。では、
290:50 ここからですね、Azureの話に少し入っていきましょう。 Azureのノーエスケールサービスの概要について学んでいきます。まあ、
291:00 いろいろあります。いろいろノーエスケールサービスあるんですが、 こちらの表にですね、主要なノーエスケールサービスの特徴をまとめております。
291:11 で、中心となるのはですね、まあ、なんといってもAzureコスモスTVになります。 AzureコスモスTV、こう、様々なところですね。こう、
291:19 名前が今出ているんですけども、このコスモスTVは非常にユニークなサービスでして、 まあ一つのサービスでドキュメントとかキーとかバリューとかグラフっていった複数のデータモデルにサービス上は対応しています。で、バックエンド側でAPIをですね、もう切り替えて使っていくような形になります。
291:38 で、このコスモスディービーなんですけども、まあ可用性の観点ですね。まあ、 マルチリージョンで、まあマルチマスターというものに対応してまして、
291:48 まあ極めて高い多様性というものを実現しています。まあ、99. 999%っていうものですね、非常に高いです。
291:54 もうこれでもう世界中のどのリージョンでも、まあデータの読み書きが可能で、まあ、 あるリージョンに障害が発生しても、
292:02 まあどこかでサービスが継続できるというような状況になっているわけです。。
292:07 あちらのノーエスキールサービスですが、 まあ既存のオープンソースのノーエスキールからの移行も考慮されておりまして、
292:13 まあ例えばですね、既存のモンゴDBアプリケーションは、 Azureコスモスピービーの方で、あのAPIとしてまあ提供されておりますし、
292:21 あのカサンドルとかもですね、対応しておりますね。はい。 Azure managed instance forバッチカサンドラは、
292:28 カサンドラをですね、使うようなサービスになります。
292:33 こちらのですね。ノーエスケールサービスの特徴ですが、 まあ細かいところをまた見ておいていただければと思います。
292:41 今の比較表でも触れました。対応性とか拡張性ですが、 まあこれは非機能要件と呼ばれるものです。アゼルのノーエスケールサービス。
292:50 まあ特にコスモスDBはまあこれらを実現するための強力な機能ですね。 まあ様々備えております。まあ代表的なものをですね、こちらに挙げております。
293:00 まあやはりこのグローバル分散とか、まあマルチマスターという機能は強力です。まあ、 世界中ノートのアゼルリージョンにもデータを分散配置することができるんですよと。結果、
293:11 超定例超定例停止とあの高可用性というものが達成されるわけですね。 まあパーティション分割とか、まあサーリングと呼ばれるような。
293:20 まあノーエスキーだったら、まあ一般的な機能はもちろん備えております。
293:25 で、一つですね、こう、あのユニークな機能がありまして、 それがこう変更フィールドというものです。これはですね、こう、
293:32 データベース内のデータの変更。まあ、つまり、こう追加をするとか更新するとかですね。 まあ、そういった操作を発生した順に記録してくれるようなサービスになっております。
293:42 サービスと言いますか、仕組みになっています。
293:45 まあ、この変更履歴を使いますと、まあ、例えばこう注文が入ったら、 まあ即座に在庫管理システムに通知するみたいな、こう、
293:53 イベント駆動のアーキテクチャみたいなものをこう構築することがしやすくなります。はい、 以上ですね。非機能要件を実現するノーエスキューエルの代表的な機能となります。では、
294:05 アゼルコスモスティービーですが、こちら課金モデルについても触れておきましょう。
294:11 まあ、アールユーベースとまあブイコアベースね。 このアールユーアールイーはこうリクエストユニットというものですが、
294:18 この二つの課金モデルがあります。左手のアールユーベースはまあスループット。 まあつまり処理能力をリクエストユニットという単位で購入するようなモデルになっております。まあサーバーレス運用とかですね。グローバル分散といったような、まあコスモスティービーならではの機能を使いたい場合には、こちらのアールユーベースが適。しているかと思います
294:39 まあ一方ですね、ブイカーベースの方はですね、こう、 CPUとかメモリといったコンピューティングリソースを直接指定するモデルとなっています。まあ特にその既存のボンゴティービーとかを、まあAzureに移行して、まあリソース管理をまあある程度こう予測できるようにしたいといった場合だったら、この右側のこうブイカーベースとかがあの非常に優れている鍵モデルだと思います。ではですね、最後ですね、あのサービスの使い分けのところになりますが、まあ。このフローチャートが
295:08 一つ指針となります。 まずキャッシュのような超高速のアクセスが必要なインメモリデータベースの場合でしたらこちらですね、Azureマネージトレディストいうものが非常に良いんです。で、そうでなければ、まあ既存のオープンソースのデータベースから移行するのが否かというところを考えていくと良いです。まあ、例えば、Azureマネージトインスタンスフォーアバッチカサンドラだったらカサンドラの互換サービスに。
295:37 なりますし、まあ、それ以外のですね。まあ、 つまりこうAzureネイティブで開発するといったような場合だったら、
295:45 まあ扱いたいデータモデルに応じてですね、 必要なコスモスDBのAPIをこう選んでいくというのが基本的流れになります。はい、
295:54 以上ですね。こちら本節の内容は以上となります。 Azureが提供しているnosqサービスの概要の部分を学びました。やはりこう、
296:03 AzureコスモスTVというものが非常にこうユニークで、あの。
296:07 大事なサービスとなっていきます。では最後ですね、 Azureのno sklデータベースの利用しないよ、
296:14 というところを説明していきたいと思います。いろいろnoskのサービスありますが、 まあ、違いは少しあるありそうだとわかった、とまあ、
296:23 どういう場面で使っていけばいいんだろう、というふうに気になると思います。
296:31 こちらのですね。まあ表の部分にですね、まあ、 各ノーエスケールサービスが適している場面というものをまとめておりますので、
296:39 細かいところはぜひ見ていただければと思いますが、まあ、ベクトル検索などですね。 AIアプリケーションを構築したいという場合でしたら、
296:47 AzureコスモスTVフォーノーエスケールとかAzureコスモスTVフォーボンゴディービーといったものがそのAI機能を持っておりますので、ぜひこちらを活用するということになります。で。この後の
296:58 スライドですね。このOSケールの利用シナリオのところ二つまた説明したいと思います。 まず一つ目がグローバル分散アプリで、
297:09 2つ目がAIアプリベクトル検索の活用の話をしていきます。 一つ目グローバル分散アプリの例ですが。
297:18 世界中にですね、ユーザーを持つようなサービスあると思います。で、 どの地域からアクセスしても応答が早くて、
297:25 かつ可用性が高いということが求められるケース多いと思います。こういった場合、 やはりAzureコスモスティービーが大活躍します。まあ、簡単な操作でですね。こう、
297:35 世界中のAzureリージョンにデータを複製することができるマルチリージョン機能というものを備えています。
297:41 で、 さらにすべてのリージョンで読み書きができるようなマルチマスター構成というものもできますので、ユーザーに最も近いリージョンでデータ処理するといったようなことができます。まあ、結果として、まあ、世界規模で極めて低いレイテンシーというものを実現することができます。では、2つ目のシナリオを見ていきましょう。このAIアプリですけれども、まあ皆さんも最近よく耳にすると思いますが、生成AIですね、これを活用したアプリケーションになります。
298:11 こちらですね、AIエージェントというのが出ていますが、 個人の好みに合わせて旅行プランを提案してくれるようなAIエージェントをですね、
298:20 考えてみたいと思います。このAIエージェントは、 ユーザーとの対話から希望条件を把握して、
298:26 まあ膨大な旅行関連のドキュメントを元にして最適な旅行プランを提案しているということが役目としてあります。で、このようなAIアプリケーションのですね、こう、裏側で。
298:37 データベースというものは非常に重要な役割を担っていまして。 旅行のパンフレットとかホテルの情報とか、口コミといったようなデータというものは、
298:45 もう形式が様々なんですね。形がこう五つねこう整えるのが難しいんです。なので、 そういったデータも、AzureコスモスTVだったら、まあスキーマですね。
298:55 あの保存できるとドキュメントデータベースに入れられるというところが非常にやりやすいわけです。
299:00 で、さらにアジェールコスモスTVとかでしたら、 こうAIによるそのベクトル検索といったようなものもできますので。
299:08 まあ単なるキーワード検索じゃなくて、 まあ文章とか画像の意味の内容にこう踏み込んだような検索とかもやってくれると。
299:15 まあそういったところが、やはりこういったデータベースの新しい機能の強みになります。
299:22 はい、以上ですね。丸一番と丸二番、二つのシナリオを説明しましたが、他にもですね、 リアルタイム分析とか、あのイーコマースの事例とか、アイオーティーとかですね。
299:33 あと最後ゲーミングのシナリオとかもあります。ぜひこちら四つのシナリオですね。 お目を通していただければと思います。はい以上ですね。
299:42 ノーウェイスケールサービスの利用しないの内容は終了となります。
299:46 第二章の内容はですね、すべてこれで終了となりますが。 noエスケールの部分ですね。しっかり押さえてください。
299:54 やはりrdbとは少しこう性質も違いますし、利用シナリオもですね。 ちょっと変わってくると思います。はい、あ、こちら第三章ですね。失礼いたしました。
300:03 はい。第三章のところはnoエスケールをしっかり学びました。
300:09 はい、ではここまでの内容でアールディービーとノーエスケールですね。 この二つのところを押さえていきました。それらの知識を踏まえて、
300:20 第四章データベースアーキテクチャという話をしていきたいと思います。 こちらの章では一つだけ説があります。
300:29 データベースを伴ったシステムアーキテクチャというものを学んでいきたいと思います。
300:37 ここまでの章で、rdbとノーエスケールというものを学びましたので、 その組み合わせのところですね。しっかり考えていきたいと思います。まあ、
300:46 rdbとかノーエスケールは、まあシステムアーキテクチャの上で、 まあどのように組み込まれていくのでしょうか。では、さっそく見ていきたいと思います。
300:55 今まで学んだデータベースですね。まあ、 他のサービスと一体どういうふうに連携されるんだろうかと少しちょっと疑問を思うかもしれません。その連携の部分を今か。ら。学んでいきます
301:09 資料の方では全部で五つのアーキテクチャ例をまとめております。で、 今回の講座はですね、丸一と丸二の部分を説明していきます。
301:20 他の三つのアーキテクチャもよくある例ですので、皆さん各自でですね、 お目を通していただければと思います。では丸一です。
301:30 標準的ウェブアプリケーションのアーキテクチャ例のところを見ていきましょう。
301:37 え、データをためる？処理する？そしてユーザーに処理したデータを見せるですね。 このウェブにおけるサービスの基本というものをシンプルに体現したのが、
301:48 こちらの酸素アーキテクチャというものです。え、スライドの例では、 パース型で提供されているAzure APP serviceおよびAzure
301:58 functionsですね。
302:00 これでフロントエンドとバックエンドを開発しつつ、 データベースをAzureマネージドレディスとAzure SQL database、
302:10 これで実装をしています。 標準的なクラウドアールディービーであるAzure SQLデータベースを採用しつつ、
302:17 データキャッシュを使って高頻度でアクセスされるデータの読み取りは高速化していこうよ、 という構成ですね。この構成は極めてよく見る構成になります。
302:29 で、この二つのデータベースで、これパース型なんですね。なので、お客さんまあとしても、 まあ、サーバーのああ管理とかからなるべくですね、開放されるので、非常にこう、
302:38 負担がちっちゃくなっていくものなんです。お客様のクラウドのメリットというものですね。 感じやすい部分になります。で、こういったアーキテクチャはですね。まあ、
302:47 そこまで大規模なグローバル展開ではないが、まあ、 新規スモールスタートアップとして、あのウェブアプリケーションをさっと開発。
302:55 したいというケースにですね。非常に適しているものです
303:00 では続いて、昨今のビジネスの現場でですね、まあ、 頻繁に導入が検討されているアーキテクチャを説明していきたいと思います。ラグです。
303:10 ラグによるナレッジ検索応答のシステムになります。 組織内に溜まったデータというものを効果的に活用していこうよと。
303:19 業務効率化の効率化を上げるとか、迅速な意思決定を支援していこうよというのが、 このラグによるナレッジ検索の。
303:27 仕組みの目的になります。このラグというシステムなんですけども、 もうデータベースと、そしてこうAIサービスというのが関わってくるんですね。
303:39 このラグではユーザーの質問に対して、まず関連する情報を検索します。で、 それをもとにAIがですね、精度の高い応答を生成するような手法になります。
303:52 で、これ何がいいかと言いますと、まあ従来のですね、まあFAQとか、 まあ単なるマニュアルでは実現できなかったような、まあ柔軟なですね、
304:01 ナレッジ活用というのが可能になるわけです。で、 このアーキテクチャではAzureの各種サービスをですね、
304:08 この組み合わせてラグを実現しています。 ユーザーの質問はまずAzureアップサービスを通りまして、
304:14 まあベクトル検索というものを返して、 質問に関連するデータというものがデータベースから返ってきます。
304:22 で、この検索結果が、質問の内容とともにAzureオープンサービスの方で駆動している。 まあ、AIサービスの方でですね、まあ、渡されまして、
304:32 生成AIの方が文脈にあった自然な回答というものを返すということができるわけです。 まあ、単純なFAQよりかは、より情報がリッチなですね。まあ、
304:42 応答というものができてくるわけです。で、こちらデータベースを組み合わせておりますが。
304:48 このアズル、エースサーチだけではなくですね。まあ、 エスキーエルデータベースとかコスモスティービーをこう組み合わせることができます。で、
304:56 こうしますと、いわゆるテーブル形式の構造化データもナレッジに入れられますし、 テーブルでは表されないような非構造化データの方もナレッジとして含めることができるんです。なので、組織に溜まっているデータというものをもう包括的にですね、取り組んだようなナレッジ活用の基盤というものができるんです、これ。が。こう生成アイが出てきたことによってもう出てきたあの登場したですね。まあ非常に
305:17 あの高機能な検索システムになりますで、当然ですね。こういったサービスとかは、 まあパース型で提供されていますので。
305:25 まあスケーラビリティとかセキュリティも一定担当されております。 エンタープライズ環境にもですね。まあ、
305:32 安心して導入できるというのが非常に良い点になりますね。はい、これ丸二番です。 マルッジ検索応答システムの例でございます。他にもですね様々な。
305:43 この例、アーキテクトの例ありますので、ぜひ皆さんお手元で確認してくださいはい。 こちらの章はですね、以上となります。
305:53 Azureのデータベースサービスが用いられているアーキテクチャ例を私の方で二つ説明をいたしました。はい、こちらの章はですね、まあ、以上となります。
306:06 やはりデータベース単品ではですね、なくてですね。まあ、 他のサービスと連携することによって、まあ一つの大きなシステムができて、
306:14 ソリューションという形でお客様の課題を解決していくということになりますので、 やはりこの連携の部分はですね、大事にしていただければなというふうに思います。
306:25 以上ですね。第四章のまでの内容は終了となりますはい、 それでは16時20分となりましたので、トレーニングを再開したいと思います。
306:34 画面の向こうの皆さんはですね、お戻りいただければと思います。はい、ではこの後ですね、 16時20分から19時十分をですね、目安としておりますが、最後ですね、
306:47 データベースのところ、残りの567章の部分をですね、 しっかり学習していくというふうにしたいと思います。もうひと頑張りです。皆さん、
306:57 頑張っていきましょうでは資料の方戻りまして第五章ですね。ガバナンス。
307:03 セキュリティコンプライアンスのところ、皆さん開いてもらえればと思います。はい まあ、こちらもそうですね。セキュリティの講座もありましたので、まあ、
307:13 そこの部分で出てきた内容もあるかと思います。まあ、少しこう思い出しながらですね、 あの学習を進めていければなというふうに思います。
307:23 このショーではまずこのジーエスシーですね。あのガバナンス、 セキュリティコンプライアンスという言葉の意味をですね、改めて確認します。
307:32 。次に、 それを実現するMicrosoftの主要なサービスとデータベースとの連携方法の部分ですね。こちらの部分について学んでいきます。そして、スキアナ構成の基本要素について学ぶ最後に、コンプライアンス要件や監査にAzureの機能を使って、どのように対応していくのかを具体的に見ていきたいと思います。こちらのショーのゴールですが、これまで学んだですね。データベースの機能に加えて。
308:01 Gscの三つの観点を踏まえた提案ができるようになることが大事になります。 お客様がAzureのデータベースサービスを安心安全に利用するための方法というものをしっかり身につけていきましょう。では、まず、このgscですね、この言葉の意味から考えていきましょう。これはですね、まあ皆さんすでにこう学習済みではあるんですけども、まあ、例えばこういうふうにですね、会話があっている時にですね。まあ、これからのシステムにはgscという観点が必須ですよ。
308:32 御社の基幹システムではgscにどのように対応されてますか？というふうに問われた時に、 あれ？そもそも何の略だっけ？っていうふうになってしまいますと、これはなかなかですね、
308:42 あの危ないことになってしまうかと思います。このgscですが、ガバナンス、 セキュリティ、そしてコンプライアンスという言葉になりますね。
308:50 このような頭文字をとった言葉です。
308:53 ガバナンスはアクセス権限の管理とか、データの分類といったルール作りですね。えっと、 ルール作りと統制の部分を意味します。セキュリティの部分ですが、
309:06 不正アクセスや改善といった脅威からデータを守ることを意味しています。 そしてコンプライアンスは、
309:13 個人情報保護法といった法律や業界標準を遵守することを意味しています。 これらのジーエスシー三つですが、なぜ重要か？
309:23 これはあのセキュリティ構造とかですね。しっかりこう学んだかと思いますが、まあ、 これをおろそかにすると、もうとんでもないことが起こってしまうからということですね。
309:32 まあ、ガバナンスがおろそかになりましたら、情報が意図せず漏れて、 セキュリティが脆弱であったら不正にアクセスされて、
309:39 まあコンプライアンス違反すれば法的な責任とかですね。 あの社会的な信用というところが落ちてしまうというところにつながってしまうと、うん、
309:47 まあ、これらはもうある。意味こう三位一体ですね。 まあ組織のデータを守るための土台というものになります
309:55 gsc、この三つですね。改めて見ていきましたが、以上のように、まあ、 gsc、この三つはデータを扱う組織の、
310:03 まあ持続的な成功というものには欠かせない要素となります。ではこの三つですが、 具体的にですね、
310:10 これらを実現するためのMicrosoftのサービスを見ていきたいと思います。
310:18 Azureにはデータを守るためのサービスが数多くありますが、 それぞれ役割があるんですよね。この二つで改めてですね。
310:25 それら使用サービスを整理して理解していきたいと思います。
310:31 やはりこのデータというところに踏まえますと、この五つのサービスがですね、 とても大事になります。Azureモニター、Azureポリシー、
310:39 Microsoftパワービュー、Microsoftセンチナル、 そしてMicrosoftディフェンダーフォークラウドですね。
310:47 まあこれはもうある意味こう暗記みたいな感じで、 もう頭の中にこう染み付かせるぐらいでもいいかなと思います。はい。まあ、これらの内容、
310:55 サービスはですね、セキュリティの講座でも。
310:58 出てきましたものなので、まあ次のページから。あ、各サービスの役割というものですね。 まあ、端的にあのポイント説明をしていきたいと思います。はい、
311:08 まずAzureモニターですね。データベースと連携しまして、 メトリックやログとかトレースをまず取ってくれます。
311:17 リソース全体の健康状態を監視するサービスと言えるでしょう。 CPU使用率などのメトリック、それをですね、収集して分析して。
311:26 Microsoftの聖地などなどに送ってですね。まあ、脅威情報の分析など、 こうにやってもらうといったところ、まあ、
311:35 こういった連携のところですねになってくれるサービスになります。まあ、 データを取るんだったら、このAzureモニターを入れてあげる必要がありますよと。
311:45 では続いてAzureポリシー言っていきましょう。 これはリソースが組織のルール通りに作られているかをチェックするものですね。
311:54 まあ、そのルールをですね、リソースに対して強制するということができるサービスですね。 ルール違反の操作というものをこう未然に防ぐためのサービス、
312:05 これがAzureポリシーになります。では、Microsoftパービュー、これ、 どんなサービスだったでしょうか？このパービューですね。
312:15 パービューは組織内のデータの資産を可視化するサービスですね。
312:19 データ見える化のためのものですが、まあ少しこう、専門用語で言うと、こう、 データカタログと呼ばれるようなですね、あの機能を持っております。まあ、組織において、
312:30 まあどこにどのようなデータがあるのかを把握して、で、 かつそのデータをスキャンしてですね、機密情報の分類とか、
312:38 そういったところまでやってくれるもの。これがMicrosoftパービューになります。 では続いてMicrosoftセンチネル。これ一体。
312:47 どんなサービスだったでしょうか。このMicrosoftセンチなんですが、 終わりところですね。こう攻めの動きをするわけですね。様々なログをまず撮ってきまして、
312:59 もらいまして、それを分析するわけです。で、分析して、まあ脅威と言われるような、 まあ高度なサイバー攻撃の兆候とかを検知するようなサービスになっておりました。
313:13 ですね、まあ、このMicrosoftセンチさんを使うことによって、 まあ脅威というものを、まあ事前になるべく早く検知して、
313:21 アクションのところまでこうまとめてやってくれと、こう、自律的にですね、 その対処までやってくれというのが、このセンチでのすごいところになります。
313:30 では最後のサービスです。Microsoftディフェンダーフォークラウドになります。 これはどんなサービスだったでしょうか？これはセキュリティ診断士のような？
313:41 あの役割ですね。クラウド環境のセキュリティ設定というものをこう評価します。で、 脅威からの保護というものをこう継続的に行うためのですね、サービスになります。まあ、
313:50 弱点はこういうところですねみたいな、こうして指摘までやってくれるようなものです。 まあ例えばこういう形でですね、このサーバーなんかよく見ると、
313:59 セキュリティパッチ全然未使用ですよと。全然適用してないですよとなったら、 まあ脆弱性アラートというものを出して、こう修正してください。と。いうよ、
314:07 うなことを人間にこう言ってくれるわけです
314:13 はい、今五つのサービスですね。簡単に振り返っていきましたが、これらのサービス、 この画面の出てるよりですね、これ連携してこそ価値が発揮されるものです。まあ、
314:22 これ全部ですね。必要なんですね。こう、一つでも欠けてしまうと、どこかにこう、 セキュリティのこう穴がポンと開いてしまうことになります。
314:30 ポリシーが作成時のルールを強制しまして、 Microsoft power viewの方ですね。
314:36 これがデータの中身というものを分類管理してくれます。
314:39 で、Azureモニターでデータをですね、しっかりこう取ってあげまして、 取ったデータとかをMicrosoftセンチに送ってあげて分析をしますと、
314:49 Microsoftディフェンダーフォークラウドはですね、こう、 リソースの設定の弱点とかをちゃんとこう突いてくれるわけです。はい、こちらですね。
314:59 まあ、セキュリティ講座のところ、改めたこそ、そしてです。 復習みたいなところがありますが。
315:06 これら五つの使用サービスはとても大事なものですので、しっかり役割をですね、 把握しておいてください。以上で、こちらの施設はですね、終了となります
315:16 続いてですね。。先ほどサービスのことを学びましたが、 まあガバナンスサービスやセキュリティサービスの連携の部分ですね。まあ、
315:25 こういったところを少し見ていきたいと思います。
315:32 まあ、それぞれのサービス単体でですね、様々な機能を持っていて強力なんですけれども、 やはりですね、こう連携をしていくと、サービスをですね、
315:42 つなげていくというのが大事になってきます。この連携方法の部分についてですね、この後、 学んでいきたいと思います。で、まず。
315:51 こういったサービスをですね、まあやみくもに導入してしまうというわけではなく、 やはりこう目的を持ってですね、まあ段階的にこう連携させていくのも大事かなと思います。
316:00 まあ、基盤構築、データ資産の理解、そして高度な脅威対策という形で、 まあ三つのステップで大まかに分けられるかなと思います。で、まずですね。
316:07 まあ最初のステップ。こう、 セキュリティとかを固めていく最初のステップとしてやっぱ大事なのが、
316:12 やっぱりAzureモニターとの連携になります。まあ、 まずこのデータをとっていかないとです。ね。まあ、
316:17 システムの見える化ができませんのでまあ、管理というものもできないですね、
316:21 なので、まずAzureモニターなどを使って、 データソースからパフォーマンスに関するメトリックとかカンサルーとかをちゃんと取りましょうよとまず取ることからスタートしていければ、その後分析するといったアクションがつながっていくわけです。まずはAzureモニターと連携をしていきましょう。で、このAzureモーターを使うと、そのセキュリティなどの関してですね、まあ、基盤みたいなものがまあできてくるわけなんですけども、まあ、基盤構築のもう一つの柱がですね。このAzureポリシーになってきます
316:51 これでこう未然に防ぐということができるわけですね。データベースが作成とかされる際に、 守るべき最低限のルールを自動で適用してくれると定義されたポリシーというものをリソースに自動的に割り上げてくれまして、違反違反してないかどうかをちゃんと見てくれるわけですね。
317:11 まあ、これで守りが固まるわけですね。基盤が良い関係になります。 設定ミスによるセキュリティホールというものが生まれるのを未然に防ぐことができまして、
317:20 ガバナンスというもののこうベースサインが確保されるわけです。で、ここまでですね、 土台に相当するところですね。まあ基盤が整うわけなので、
317:27 まあ次からまあ集めたデータとかをちゃんとこう理解していくということになります。 データ資産の理解ですね。で、ここでまあ、
317:34 Microsoft power viewというものが使えるんですよ。と。 話をしました
317:39 パービューをデータベースに連携することで、カードのデータの集まりというものが、 まあどこに個人情報があるのかとか、まあどのデータがビジネスを重要かといった、
317:50 まあ意味のある情報資産として見えてくることになります。なので、基盤を作ったら、 データ資産の理解、Microsoftのパービューの連携というところをですね、
318:01 図っていくと良いでしょう。で、 最後のステップがやはり高度な脅威対策というものになります。
318:08 まあ、Microsoftモニター。あ、失礼しました。 Azureモニターですね。
318:13 Azureモニターでなどを導入することによってちゃんとデータが取れているという状況なのですが、じゃあそのデータ活用していこうと。セキュリティをですね、強化していくために活用していこうということで、Microsoftステージしているということで、ナースサービスを入れていきましょうと。で、この後、前説明しましたですね。あのディフェンダーフォークラウドな。ど。も連携す。るとまあさら、に強力なセキュリティに対するこう強化が話されるわけです
318:37 まあ、データベースから、まあ様々なログが出てきますので、まあ、このデータをもとに、 まあ共有件数などをしまして。ルールに基づいてですね、
318:47 規定のアクションを自動的にとってもらうということになりますと、 やはりこうセキュリティに関して、こう攻めの指定もできますので、
318:56 より強力なセキュリティ、ガバナンスなどの仕組みができるわけでございます。はい。 まあ、このように関してですね、まあ、まずその監視とかルールの基盤作り。
319:07 まあ、データを取るところから始まる始まりましょう、ポリシーをですね、 ちゃんと強制するところから始めましょうっていうところからスタートして、
319:15 じゃあ次データの中身を理解しましょうまあ、パービューでですね、 データスキャンして管理していきましょう、で、最後に高度な脅威を検知とかですね、
319:23 対応していきましょうというふうにですね、まあ、段階的に連携させていきますと、まあ、 包括的で深いセキュリティというものが実現できるわけです。以上ですね、こちら。連携。
319:32 のセクションは終了となります。
319:37 ではですね、この後なんですけども、まあデータベースを含むリソースというものを、 まあセキュアにですね、構成していく方法について学んでいきたいと思います。
319:47 やはり不正な侵入というものがやはりセキュリティ上非常に危ないと思います。 リソースに対して、まあ誰にも侵入されないようにするためには、
319:56 一体どういうことをしていけばよいのでしょうか。そのための基本となる考え方をですね、 見ていきましょう。
320:04 で、今回セキュアな構成として抑えていただきたいのは三つです。まず、 この三つをしっかり押さえてください。セキュアな構成を実現するためには、
320:14 まず一つ目MicrosoftエントラIDによる認証で、2つ目がプライベート接続、 そして3つ目が暗号化になります。一つ目のMicrosoftエントラIDですが、
320:26 これはAzureクラウドサービスに安全にログインするための仕組みになりますね。
320:33 こちらにMicrosoftエントラIDによる認証、もう推奨と書いてますが、 まあこれはもう基本的なあのAzureの仕組みになります。
320:41 これをもう基本使っていきました。で、それと従来型の認証ですね。まあ、 パスワードなどを比較しているもの表でまとめております。
320:48 まあ細かいところはですね、ぜひ見ていただけたらなと思うんですけども、 もう端的に言うと、もう従来のパスワード認証とかに比べると、まあ、
320:57 多要素認証とかですね、条件付きアクセスといった機能で、 もうアイディーに対するセキュリティをもう大幅に強化することができているよということです。なので、これをこう使わない手はないですよということですね。。2つ目、プライベート接続という話がありました。
321:12 まあ、 データベースをインターネットの脅威から隔離するというのは非常に大事な試みになります。
321:18 そのための仕組みがプライベートです。具体的なサービスですと、こちらですね。 Azureプライベートリンクと呼ばれるようなサービスがあります。これを使いまして、
321:28 お客様専用の仮想ネットワークの中にデータベース。
321:32 への入り口を作ることができます。仮想ネットワークの中に、 データベースへのプライベートな出入り口である
321:38 プライベートエンドポイントというものを作ることができます。これによってですね、 データベースというものはこうインターネット上に公開されているような、
321:47 まあパブリックアイピーアドレスないのまだ持たなくなりまして、 まあバーチャルネット内部のアプリケーションからのみアクセスできるというような仕組みを作ることができます。
321:57 またですね、ここもですね、押さえていただければと思うんですけども、 まあオンプレからですね、まあ、Azureにこう接続するということはあるかと思います。
322:06 で、そういった時もAzureエクスプレスルートなどの専用線などを使うことができます。 で、これをバーチャルネットにこう接続することができれば、
322:16 通信経路をすべてプライベートに保つことができまして、 不正アクセスというものをアーキテクチャレベルで防ぐことができるんです。はい、
322:24 こちらプライ。ベ。ート接続の内容でした
322:27 で、最後ですね、3つ目、暗号化という話になります。まあ、これはまあ、 ある意味こう基本中の基本かもしれませんね。
322:34 データというものを第三者に読み取られないようにする技術になります。 アズールにおいてはですね、まあ、この通信の暗号化というものは、
322:43 まあ基本的な機能でございますので、通信経路とかですね。まあもう規定で暗号化されます。
322:50 ただ、アプリケーション側でデータを暗号化するですね。まあ、 always encryptと呼ばれるような機能とかもあります。まあ、
322:58 基本的にすべてのデータサービスで、もう通信の暗号化とかはされるんですけども、 こちらですね、この製品は押さえておくとよいでしょう。
323:05 Azureエスケールデータベースとか、 Azureエスケールマネージドインスタンスなどは、
323:10 このデータに対する暗号化というものが強力にすることができます。 これティーディーイーとあのアティーディ。ー。のこのエス。
323:16 エムケーとシーエムケーという暗号化のしてるんですね。
323:19 まあ、こういったものをかけることができます。まあ、 ここの部分がまあ他のデータベースとはちょっと違う部分になりますので、まあ、
323:28 エスケールサーバーベースのこれら二つのデータベースは、そういうセキュリティ面で、 まあ強い特徴を持ってるんだということを一つ押さえていただければと思います。はい、
323:39 以上がですねえ、セキュアな構成という話でございました。三つの要素が。
323:43 ありましたね。。MicrosoftエントラIDによる認証とプライベート接続、 そして暗号化と話し合っていました。これが三つはですね、
323:55 基本的な要素になりますので、しっかり押さえておきましょう。 では続いてガバナンスセキュリティ。という文脈ですとですね。
324:05 まあもう一つ大事なのが、このコンプライアンス要件対応というもの。
324:13 まあ、コンプライアンスは大切ですというふうな言葉はよく見聞きするかと思いますが、 まあ具体的に何をすればよいのかというところが、まあちょっとこう、難しい、
324:23 わかりにくい部分があるかと思います。で、Azureではですね、まあ、 どのように対応していくのかというところを説明していきます。はい
324:32 まず理解すべきですね。まあ、最も重要なコンセプトというのが、まあ、 この共有責任モデルになります。
324:41 まあこれはセキュリティに関する責任を、 クラウドを提供するAzure側とそれを利用するお客様側で分担するという考え方でした。
324:49 まあ、例えばパースにおいては、 まあ物理インフラの管理は基本Azureの責任なんですが、
324:55 そのパースで動かしているデータそのものの保護とかアクセス権の管理というものは、 お客様のまあ責任となります。うん、なので、まあしっかりですね。
325:04 ここをお客様側にもまあ伝えていく必要があります。
325:07 で、もちろんそのパーソナルのサービスはお客様自身でやっていかないといけない、 管理していけないいけない責任の部分もあるんですが、やはりAzure側としてもこう、
325:17 そこをお客様にやりやすいで、こう支援していくという方向性はとても大事だと思います。 コンプライアンス要件含めてですね。
325:24 まあ様々なことをお客さんお客様がやりやすいように。 まあAzureは様々な機能というものを提供しております。まあ、
325:31 スライド表でまとめておりますが、まあ。データ。保護とかですね。
325:34 このあたりはもうもちろんやっておりますし、先ほどのMicrosoft、 エントラIDといったものありましたが、このアクセス制御とかももちろんできます。で、
325:43 監査に関する機能とかですね、そういったところももちろん備えておりますので、 まあお客様の方に、
325:49 あのこういったサービスであのお客様の責任の部分とかも支援できますよというふうにお伝えするのは、とても大事な部分だと思います。
325:58 で、このコンプライアンスということに関しまして言うと、ここは結構大事になります。 Microsoftサービストラストポータルというものですね。お客様によっては、
326:08 Azureというプラットフォーム自体が信頼できるのかということを、まあ証明をですね、 求めてくる場合があるかと思います。まあ、その場合に、
326:16 このMicrosoftサービストラストポータルというものを利用することができます。 このポータルサイトではISOとか。
326:24 エスオーシーといった第三者機関によるAzureの監査レポートとか、 まあ各種コンプライアンスの認証情報というものを検索してダウンロードすることができます。なので、お客さんにですね、まあ自信を持って、Azureというプラットフォームは大丈夫ですよっていうことをお伝えできるわけです。はい、ここまでですね、コンプライアンス要件の対応という話をしていきました。業界規制とかですね。法的要件というものもやはり大事になりますので、まあ、そういったと。ころにもきちんと対応をしていきましょう
326:55 ではですね、本書最後のセクションとなります。監査対応というものです。 システムの監査ですね。これは避けて通れないテーマとなります。
327:05 後のして大丈夫になっていってですね。まあ、大怪我をするわけですね。はい。まあ、 いろいろこうやらないといけないこと、たくさんあります。
327:13 アズレガではどのように監査対応を効率化できるのか、その仕組みを見ていきましょう。
327:20 はい、簡単対応ですね。まあ主な作業としては、まあ、例えば六つほどあります。 まあ、ログの記録の収集とか整理とかですね。適切なアクセス制御の証明などです。まあ、
327:33 データベースにおいて言うと、ま、あいつ誰がどのデータに何をしたのかという操作ログ、 これがまず正確に記録してあって、
327:42 きちんと追跡可能にしておくということが基本になります。まずもうデータ取りと。
327:49 いう部分ですね。うん、データがあれば、 一体どんなことを行われているかっていうのを客観的にを示すことができるわけです。
327:55 これはもう社外に対する守りだけじゃなくて、こう、社内に対してもですね、 こう守りを固めるという点で非常に大事になります。まあ、社内のユーザーがですね、まあ、
328:04 もし万が一ですね、なんかこう、不正なことをしてたとして、まあそれを指摘するときに、 まあ、僕が社内で不正したあの証拠ってあるんですかと言われたら、まあ、
328:12 データがなかったら。何も。言えないわけですね、
328:15 なので、きちんとデータを取っておく必要があるんです。いや、 あなたはこの時にこんな操作してましたよね。データベースのログを取ったら、
328:21 こんなことがちゃんと出てくるんですよっていうふうに、 こうさんと言えるっていう状況を作れているか。
328:27 これがいわゆる監査の対象になっているわけです。
328:29 で、各データベースでもちろんですね、その監査対応の記録を持っております。 もう端的にきちんとまあログを取る機能があるんですよ。
328:38 ソーサルを記録するための仕組みがちゃんとどのサービスにもあるんですよっていうところをまず押さえていただければオッケーです。まあ、これが標準で組み込まれております。はい、こちらはアールディービーサービスですね。監査機能概要になります。で、もちろんノーエスケールの方もですね、あります。
328:58 Azureコスモスディービーとかでしたら、 こう診断ログという監査対応機能とかって言いますが、
329:04 もうこういったのはもう必ずオンにして、 もうログというのがちゃんと保存されるようにしておく必要があります。まあ、
329:11 これらのログを活用して何か問題が発生した時には原因を素早く特定することもできますし、 不正な操作とかがあった時もですね。まあ、検知したりすることも可能になるわけです。
329:22 まず。
329:23 各データベースですね、監査対応機能っていうのを標準で組み込まれていますので、 きちんとそれを使っていくという、この心構え、スタンスの部分を抑えてくださいはい、
329:34 ではですね、以上でこちら監査対応の施設は終了となります。 各データベースの監査機能を活用して、ロゴを適切に管理していくことが大事になりますで、
329:45 以上ですね。第五章の内容は終了となります。はい。
329:50 まあ、ガバナンス、セキュリティ、コンプライアンスという観点で、 データベースとも関わりのある部分をですね、メインに、
329:59 ついメインに説明をしていきました。まあ、この三つですね。まあ、gscの観点はですね、 お客様の信頼を獲得する上では不可欠な要素かと思いますので、まあ、しっかりですね、
330:11 ここの内容は押さえておいてください。以上で、第五章の内容は終了となります。はい。
330:17 ではですね、データベース講座ですね。まあ全七章となるのですけども、残りですね。 第六章、第七章という風になっていきます。ダイレクトですね。
330:29 運用の章になります。まあ、データベース開発した後に運用していかないといけませんが、 今回は運用に関して大きく三つのことを学びましょう。一つ目モニタリングです。で、
330:41 2つ目はパフォーマンス最適化で最後、デブオプスデータオプスの話です。
330:50 本社の学習を通じてですね、パフォーマンスとコスト効率を最適化するための手法、 そしてデブオプスデータオプスというデプロイ後のライフサイクル管理に関するスキルを習得していきましょう。では、まず一つ目ですね、運用モニタリングについて学習していきましょう。まあ、データベースに何を悲しい入れてないとですね。ま、あいつのまにか、まあ、こんなふうに。
331:16 ストレス使用率95%といったような、 もうとんでもないことが起こり得る可能性があるわけです。
331:22 データベースの異常というものにはいち早く気づく必要があります。ここでですね、 データベース関しての基本的な流れを抑えましょう。まず一つ目、監視目的を決めます。
331:34 パフォーマンスなのか、障害なのか、 それが決まったら監視対象の状態を評価できるメトリックを決めます。CPU使用率なのか、
331:43 メモリ使用率なのか。
331:45 運用時には決定したメトリックを追っていきます。そして、異常というものですね。 みなすためにはですね、何らかのこう、閾値を設けます。で、閾値を超えてですね、
331:56 バラードルール設定して、閾値を超えてですね、 異常と判断された時にはアラートが発行されるようになして、
332:04 アラートの内容に踏まえて人間がアクションをとっているということですね。 これが運用モニタリングの基本的な流れになります。
332:14 データベースの監視の際には、主にですね、こういった部分のメトリックスが活用されます。 で、今回は細かいところの説明は重要ではなくて、
332:24 運用の時にはこんなにもたくさんのメトリックを追っていかないといけないんだという事実が大事になります。これらのメトリックですねに対して大きく四つのことを考えなければなりません。
332:38 まず、アラートを設定するときの、まあ重要度というものを明確化して、 次にそのアラートごとにですね、閾値というものを設定する必要があります。そして、
332:49 アラートが発生したらどうするのかで、 そういったアラートは1回決めたら終わりじゃなくて、定期的にですね、
332:56 見直しをする必要があるんです。こういった取り組みを、 それぞれの取り組みに対して実施していくという必要があるんです。
333:07 はい、こちらにですね、アラートルールの設定例を記載しています。まあ、 細かいところというよりかは、まあ、
333:14 こういったルールをそれぞれのメトリックスでさっと考えていかないといけないという部分ですね。アラートは厳しく設定しますと、アラートと言いますか、その閾値ですね。こういった識値の部分は、厳しく設定すると頻繁にアラートが出て、対応する側が疲れます。でも緩くすると問題を見逃します。なので、バランス感っていうのが大事で、アラートルールっていう。のはやっぱ見直しが必要なんで、す
333:37 なんで運用者は結構大変なんですね。なので、そういった部分を手軽にできるような、 支援できるような仕組みというのが求められるわけです。で、
333:46 AzureでではAzureモニターというものがまずですね。まあ、 そういった部分をこう支援してくれるわけですね。
333:54 もうデータをこう取れるような仕組みをこうちゃんとそれ作ってくれるわけです。 監視対象があったとして、で、こちら側ですね。
334:03 監視対象の状態をビジュアル化するようなサービスがあったとします。で、これらをですね、 こううまくつないでくれるのが、このAzureモニターというサービスになります。まあ、
334:14 繰り返しにはなりますが、まあAzureモニターではたくさんの種類のですね。まあ、 データを取ってくれるわけですね。データを収集するところここから監視は始まります。で、
334:25 取ったデータというものをダッシュボードなのに。
334:28 可視化をしてあげて、 システムの状態ってこんな感じですよっていうことをこうしっかり伝えにいくというところが大事になるわけです。で、ちゃんと可視化するだけじゃなくてですね。まあ、アラートをちゃんと出すとところ、ここも結構リッチな機能がありますし、アラート出すだけじゃなくてですね。まあ、自律的にアクションをとるといったところまでしっかりサポートをしています。なので、運用する方としては結構こう支援してくれて負担が小さくなるわ。け。ですね。
334:58 はい、今ですね、この運用という話をしていきました。あと、 アラートルートアラートルートを作るのが結構大変なんですと。で、
335:06 そこの部分とかをもうシェアしてくれる。そのAzureの会としては、 あのAzureモニターによること、
335:13 Azureモニターの導入という部分ありますので、 このAzureモニターは非常に運用においては大事なサービスとなります。
335:20 ではこの運用モニタリングの話はですね、一旦以上としまして、 パフォーマンス最適化のところ。に
335:26 目を向けたいと思います。やはりまあ、データベースを作って運用していく上では、 やはりこうデータベースのクエリの速度とかをなるべく早くしたいといった、
335:34 まあやっぱり最適なところにですね、こう目を向けていくかなと思います。まあ、 もちろんクエリ。データベースのパフォーマンスとしては、
335:42 クエリの実行速度は早い方がいいですし、まあ、 なるべくたくさんのクエリをさばけた方がいいですね。
335:50 データベースのリソースですね。 アールディービーとかはスケールアップさせますと当然パフォーマンスは上がりますが、
335:58 まあそれだとコストも上がります。なので、 リソース効率というものをうまく最大化しつつ、読み書き速度も向上していく。
336:05 これがデータベースにおいて、まあ非常に大事になります。で、 このパフォーマンス最適化をですね、補助するようなツールが大きく四つありますので、
336:15 それを見ていきましょう。
336:17 この四つはですね、大事なのでしっかり覚えましょう。一つ目、 クエリパフォーマンスインサイトというものです。このクエリパフォーマンスインサイトは、
336:26 クエリという粒度でパフォーマンスを見るためのツールになります。 データベースのパフォーマンスが悪い時はリソースの問題の時もありますが、
336:35 実行したいクエリがイマイチということもあるんですね。まあ結構あります。まあ、なので、 問題の切り上げどっちが悪いんですか？っていうのをやっぱりこうクエリかリソ。
336:45 ースかで判断しないといけません
336:47 クエリのパフォーマンス見たい的には？マル、 一番クエリパフォーマンスインサイトがすごい大事になります。クエリティ単位ではなくて、
336:57 データベースという大きな単位でパフォーマンスを見ることもできます。 それがデータベースウォッチャーです。
337:05 データベースに対する接続数が増えていく時間帯とか。
337:09 データベースのストレージ使用料といったデータベースという単位でパフォーマンス見るんだったら、このデータベースウォッチャーというですね、ツールを使ってください。では0102話をしましたが、これ見える化に関するものですね。こう、データを可視化していきましょうという話なんですけども、やっぱりチューニングまでできると嬉しいですね。で、そのチューニングに寄与するような情報を教えてくれるのが、このデータベースアドバイザーになります。
337:39 クエリの実行結果とか、インデックスの使用状況とかを自動的に分析してくれます。で、 分析した結果をもとに、
337:47 パフォーマンス向上のためにはこういうことしたらいいですよっていうアドバイスを提案してくれるんですね。この機能がデータベースアドバイザーというものになります。まずですね。今説明したクエリパフォーマンスインサイドとデータベースウォッチャーとデータベースアドバイス、これをまず押さえましょう。
338:09 で、パフォーマンス最適化という観点ですね。こう。 より広範囲にサブスクリプションとかリソースグループという単位でパフォーマンス最適化を試みたいというケースももちろんあります。それできます。Azureアドバイザーというものです。このAzureアドバイザーはデイスターベース以外のリソースから取られた監視データを踏まえて最適化アドバイスを行ってくれます。
338:36 アジアアドバイザーのポイントの一つはですね、 支出に関するアドバイスを送ってやってくれるということですね。
338:43 リソースプランの変更に関するアドバイスとか、 リソースポーツの見直しなどのアドバイスまで送ってくれる。
338:49 結構大きな単位のアドバイスをしてくれるというところがポイントになります。はい、 今ですね、パフォーマンスを最適化するためにこのツールを使いますよという話をしました。
339:00 先ほど説明した四つのツールはですね、非常に大事なものです。の。で、押さ、 えおいてください
339:07 はい、ではですね、このこの章の最後になります。運用という観点で、 まあ大事なキーワードであるデブオプス、
339:17 そしてデータオプスについて基礎的な知識を学習していきましょう。 データベースというのは、その周辺領域のサービスと連携することによって、
339:29 データの価値を最大化することができます。
339:33 連携を済ますと、必然的にですね。まあ、データの受け渡しが発生しまして、まあ、 いろいろ問題が起こるわけです。その問題がなるべく起こらないようにするために、
339:45 システム開発とかデータ管理に対する基本的な戦略と実践というものが今後求められていきます。その戦略というものがデブオプス、そしてデータオプスというものです。
339:58 この考え方では、 もう開発チームと運用チームでいいのはもう排他的な関係じゃないんだよと。
340:05 両者一緒になって継続的にシステムを改善してい*。 *して改善のためにできることはなるべく自動化していきましょうよっていうことを志していきます。デグオプス、そしてデータオプスを実践しますと、今こちらのツアーにあるようなですね。まあ、実際の現場で起こるような面倒な問題というものを解消できます。
340:28 もうわかりやすいもので言ったら、手作業によるエラーが多発するとかですね。まあ、 システム上に実はデータ処理に問題があったりして、問題があるまんま、
340:38 誤った意思決定が起こってしまうとか、まあ、 そのようなデータ活用の現場で起こりがちな問題というのを、
340:45 レポオプスやデータオプスの考え方を導入することで、なるべく潰すことができます。で、 こちらのような問題に対応していくためにはですね、大きく二つの対応が必要です。
340:56 まず一つ目は、透明性があるシステムを開発しなければならないということです。 どこにどのような仕組みがあるのかが誰にとってもわからないといけません。で、
341:06 2つ目がそういった仕組み。 システムの仕組みのアップデートとか監視とかがなるべく自動的になされて、
341:13 まあチームに余裕をもたらしていくと。で、その余裕が新しいですね。 あのシステムの改善のところにつながっていくわけです。こちらデーブオフィス。
341:23 いや、データオフィスにですね、大事なことまとめております。やはりですね、 大事なのはもうエンドツーエンドで自動化していこうという結構大きな夢ではあるんですけども、ここを目指していくという、これがですね、大事になるわけです。データの収集、処理、テスト、デプロイ、監視といったようなデータパイプラインの各工程をできる限り自動化していきましょうと。
341:48 で、 こちらに書いてあるシーアイシーディーとかは割と今広く導入されているのかなと思うんですけども、まあ今後はですね、さらに一歩進んだアイエーシーのようですね。これの導入に踏み込まなければなりません。こちらデータオプスという考えをですね、ツールを用いて具体化したものです。大きく分けますと、開発バージョン管理データパイクライン監視管理という領域に分かれていきます。
342:19 で、こちらのですね、開発バージョン管理のこのiacというもの、これ、 インフラストラクチャーアズコードの略のことなんですけども、
342:27 サーバーとかネットワークといったITのインフラ構成もコードベースで管理していきましょうということですね。まあ、一般的にキットリポジトリで、いわゆるアプリケーションとかのソースコードは、まあコード管理できるわけですね。
342:40 ただそれだけじゃなくて、 もうインフラの部分も全部テキストベースで管理していきましょうよと。
342:45 そしたら誰と誰にとってもどんな構成かわかるじゃんという発想なんです。 なので今後はですね、この開発バージョン管理のところに、
342:52 このアイエスシーというものを導入していいですね。もうどこに何があるのか、 どんなインフラが使われているのかっていうのが、
342:58 こう見える化されているのがとても大事になります。
343:03 左側に目を向けますと、まあ、データパイプラインというものがありますが、まあ、 こういったデータパイプラインところでは、
343:10 オーケストレーションツールというものを入れていくのが大事です。 これでもうなるべく人の手を入れないんですね。もうデータのソースからの実行とかですね、
343:19 管理の部分というか、もうなるべくツールでおかせしましょうと。Azureにおいては、 このオーケストレーションツールはAzureデータファクトリーです。
343:27 これがその役目を担。って。くれます
343:29 監視とか管理もうこれはもうですね、繰り返しになりますが、 まあ当然Microsoft
343:35 perviewとかAzureモニターとかを入れましょうねという感じです。 こちらの資料にですね、データオプスの文脈で使われる主なマイクロサービスを。ああ、
343:45 失礼しました。Microsoftサービスをまとめております。こちらですね、 Azure DevOpsというものがありますが、
343:52 このAzure DevOpsはこのDevOpsを行うために必要な環境とか。
343:57 有用なツールというものを揃っているサービス部になります。まあ、cicdとかですね、 ソースコードのバージョン管理といったようなキーとかがあります。で、
344:07 このAzure DevOpsの中にはですね、 このAzureパイプラインズという仕組みとかがあったりするんですけども、
344:14 このAzureパイプラインズはcicdとかiacとかですね、 こう支援してくれるようなサービスになります。
344:22 最後ですね。このアイエスシーインフラストラクチャーアズコードの部分ですね。 これを説明したいと思います。これを実現するツールはですね、
344:32 Azure上だと大きく四つあります。 バイセップアームテンプレートテラフォームプルミです。Azureだけで返すと、
344:40 運用が完結するんだったら、もうバイセップもしくはアームテンプレートです。 他の二つはですね。まあ、マルチクラウド対応ということになります。
344:51 で、このバイセップとアームテンプレートとツールですが、 バイセップの方が新しい技術になります。なので、まあ今からですね、
344:58 新しくアイエーシー導入しますよっていう時には、基本的にはこのバイセットをですね、 推奨すればオッケーでございます。アームテンプレートと比べると、まあ割とですね、
345:08 使いやすいと言いますか、まあ、シンプルな記述であのインフラを管理することができます。 はい、以上ですね。データオックス、デブオックスの導入の部分を説明しまし。た。
345:20 こちらの内容で本書は終了となりますが、データ活用の場合ですね。まあ、 周辺サービスとの連携というのはもう当たり前になりますので、
345:29 必然的にシステム全体大きくなります。なので、 もう人の目が届かないところがいっぱい出てくる。なので、まあ、
345:36 エンドツーエンドの自動化というところにこう踏み込む必要があって、まあ、 そのための基本的な戦術というのがデータオップス、
345:43 ディブオップスなんだよということを押さえていただければオッケーです。
345:47 はい、ではですね、最終章。ダイレクションが終わりましたので、 いよいよ今回のトレーニングもですね、あの終わりの方に近づいてきております。
345:58 データベース最終章です。第七章オブジェクションハンドリング事例ということで、 こちらの章を最後しっかり勉強していきましょう。はいここまでの内容でですね、
346:09 Azureのデータベースとデータベースの運用に関する内容を学んでいきました。
346:16 最後に、オブジェクションハンドリングの事例をですね、見ていきたいと思います。 お客様からよく寄せられる懸念、
346:25 そしてそれを払拭する方法というものを学習していきましょう。コスト、性能、移行監視、 可用性、そして競合比較。まあ、こういった観点ですね。見ていきたいと思います。
346:41 先ほどであげたですね、まあ七つのものなんですけども、まあ、 お客様からよく寄せられる懸念かと思いますので、
346:48 それらを払拭する方法というものですね。しっかり学び取ってくださいでは、 まずコストに関する懸念です。まあシンプルにまあいくらかかるのっていうのは、
346:58 まあお客様は大変気にされる部分かと思います。いかになるんだろうと、 ここがわからないと、
347:04 さすがに移行するっていうのは難しいなというふうにお客様思われるかと思います。
347:11 お客様がですね。持つよくある懸念、主に三つになります。一つ目、 オンプレミスからクラウドへの移行に伴い、コストが増加しそうだと。
347:24 一つ目クラウドに移行する金銭的な価値が具体的に見えにくい。 3つ目クラウドだとなんかコスト削減難しそうまあ、こういった懸念点があるかと思います。
347:39 これらの懸念点に対して、Azureとしての対応、戦略、 訴求ポイントというものを表にまとめております。まず一つ目ですね、
347:48 こちらAzureコストマネジメントプラスビーディングのところ見ていきたいと思います。 コストの増加とか価値の見えにくさという懸念に対しては、まずうちとしては、
347:59 打ち手としてはですね、 コストの可視化とティーシーオーでのコスト比較というのが有効になります。
348:07 まずAzureでは、Azureコストマネジメント、そしてリビングというツールで、 これなんですね。コスト見える化というのができるわけですね。まあ、
348:17 リソースごとに、 そしてリソースにつけたタグごとにコストの打ち上げというのを詳細に分析できますのではい。またですね、予算の設定とかもできますね。で、予算を設定して、消化しそうになったらアラートを通知するといったこともできます。
348:33 で、この超過しそうになったらという予算超過の早期建築というのは、検知というのは、 まあ極めてあのコスト管理だと非常に大事な機能になります。あの予算をが超えたら超えて、
348:43 あの通じちゃってもどうしようもないんですね。お金を使え、 たくさん使えそうだと予算以上にお金を使えそうですっていう、
348:50 その事前にコスト感に関して知っておかないといけないので、 この早期検知というのはとても大事な機能になります。
349:00 で、さらにですね、オンプレミストの比較に関しては、 tco計算ツールというものですね。非常に役立ちます。
349:08 クラウドの運用コストというものをこう定量的にですね、スタンすることができます。 こちらのようにですね、図があるんですけども、
349:18 オンプレミスのコストとAzureで使った場合のコストというものを比較することができます。
349:25 もうサーバーのハードウェア費用とかそんなものだけじゃなくてですね。まあ、 遅れの費用としては、その運用する人件費とか、データセンターの電気代とか、
349:33 まあそういったものを含めた、まあトータルのコストとかを比較することができますので、 もう包括的にですね、
349:39 もうどっちがいいんだろうとクロスではっきりつくというようなサービスが、 このティーシーオー建設になります。で、最後3つ目ですが、
349:46 まあコスト削減が難しいんじゃないかと。うん、クラウドでどう。 いうふうにコスト削減していけばいいのっていうところがお客さんが気になさるかと思いますが
349:54 これ様々なですね。まあコスト削減オプションというものが用意されております。 まあ大きくですね。まあ五つこちらの表では掲載しております。まあ、
350:04 まずAzure基本的にはその料金モデルが従量課金制なので、 まあ使った分だけでお支払いですよと。もし万が一一定期間ですね、
350:12 まあサーバーとか使わないんだったら、まあ止めておいていただければ、お金使わない、 あのお金はかからないですよっていうふうにうんでお伝えすることがまずできますよ。
350:25 で、こちらですね、Azureの予約Azure reservationsとか、 コンピューティングのためのAzure節約プラントっていうような、
350:33 こう割引のプランといったものもあります。このAzureの予約は一年とかですね。まあ、 三年とかそういった長期の単位で、
350:40 特定のリソースの利用をまあお約束していただくことによって、 従量課金制と比べると大幅に安くできますよ、というプランになります。で、
350:48 コンピューティングのためのAzure節約プランとありますと、これはですね、あの。
350:54 特定のコンピーティングインスタンスですね。それに関して、 それもこう長期で利用を約束してくださるんだったらお安くすることができますよっていう。
351:04 まあ、 そういったサービスがこのコンピューティングのためのAzureちっちゃいプランになります。で、こちら4つ目Azureスポットバーチャルマシンズというものがありますが、これはですね。
351:18 Azure環境上ですね、このAzureノート全世界にあるサーバーの仮想マシンにまあ、 あまりがあったとします。で、そういったあまりをですね、
351:26 非常にお安くお客様にご提供することができるというサービスです。まあ、ただこれですね、 注意点がありまして、基本、
351:33 あのAzure上のコンピューティングインスタンスのリソースがですね、 足りなくなってくるというような状況になりましたら、まあ、
351:41 お客様がもし使っていてもですね、突然提出するといったことがあります。
351:46 なんですごくお安く使っていただけるんだけども、まあ途中で 中断する可能性があります。なので、本番環境とかには基本的には使わないようなと、
351:54 開発とかテスト用とか、一時的にまあサーバー必要になったとか、 そういった時にはもうぜひこのプランでですね、
352:01 お安くコンピューティングリソース使ってくださいねというものです。最後ですね、 Azureハイブリッド特典というものがありますが、これをですね、
352:10 ウィンドウズサーバーとか、あのSQLサーバーの。 既存ライセンスとかをお持ちのお客様とかが
352:15 そのライセンスをAzureで利用することができますよっていうものですね。 もうオンプレイでせっかく持っていたライセンス、これどうなっちゃうんですか？と。
352:24 これ無駄になっちゃうんですか？ というふうに気になっちゃうお客さんもいらっしゃるかと思いますが、いや、
352:29 そんなことないですとAzure上でそれをお使いいただけて、 コスト削減の方でこう活用できますよっていうふうにご提案できるわけですね。まあ、
352:37 このような様々なですね。コスト削減。オ。プションというものがあります まあ他にもですね、もう料金形態だけじゃなくて、まあ、 そもそもサービスの仕組みとしてコスト削減ができるというものもあります。まあ、
352:48 いわゆるこうサーバーですと呼ばれる仕組みですね。 ワークロードの需要に応じてリソースが自動的に調節されますので、
352:55 無駄なリソース仕様というものがなくなりますはい、以上ですね。 コストに関する懸念でございました。まあ、
353:01 大きく三つほどお客様の懸念があるかと思いますが、まあ、それぞれの打ち手をですね、 きちんと説明で。き。るよ。うになっていただければと思います
353:10 では続いて性能に関する懸念見ていきましょう。 このデータは早く安全に届くかしらとかですね。
353:17 まあクラウドってどんな性能出るのかなってところに結構疑問を持たれるお客さんはいるかもしれません。性能に関してですね。非常にこう、多岐にわたるような懸念を持っているんじゃないかなと思います。もう今ですね、もう七コードあるなと。
353:35 もあります。まあ、例えばそのオンプレイリスト、 Azureをつなぐ際の通信速度とかですね。
353:40 あとは急なアクセス増加にデータベースが耐えられるんですか、とかですね。まあ、 様々な懸念を持つかと思います。まあ、細かいところはですね、
353:49 ぜひこの表の部分を見ていただければと思いますが、いくつかですね 打ち手の部分とかを説明したいと思います。まず一つ目ですね。
353:57 あのオンプレとAzure間の通信性能に関してですが、これはですね、Azure、 Excel、rootという選。択。肢。があります
354:06 閉鎖のを利用します。で、お客様専用のプライベートな接続を作ることで、 後退期で遅延が少なくて安定した高速通信というのができるようになります。性能面、
354:16 大丈夫ですよっていうことですね。クラウド上でもですね、 通信時間に気になさるお客さんいると思います。
354:23 バジル上でバーチャルマシンいっぱい作りたいんです。で、 バジル上のバーチャルマシンの通信性能ってどうなってるんですかという懸念なんですけれども。
354:33 複数のバーチャルマシンをですね、あの近接配置する仕組みがアズル上にはあります。 まあ、物理的に近い場所にですね、サーバーをありましてで、
354:44 その中であの近いバーチャルマシン同士をこう通信させるという仕組みになります。なので、 こう、バーチャルマシンからのネットワーク通信にかかる時間がですね、
354:55 極めて小さくなりますので、まあ速度面も問題ないですよと。
355:00 アプリケーションの応答性能を最大限に高めたいんだったら、 この近接配置グループというものをぜひ検討してくださいというふうにお客様にお伝えすることができます。で、アプリケーションのですね、応答速度を高めるという観点だと、まあ他にもですね、いろいろできまして、まあ、例えばAzureマネージトレディスとかですね。これはキャッシュを用いて応答速度を高速化することできます。
355:26 で、データベースという観点でも、データベースの一時的な処理速度ですね。 こう上げたりすることもできます。これ、バースト機能と言ったりしますが、
355:34 AzureコスモスDBとかですね。まあ、 多くのそのSQLサーバー系のデータベースだったら、まあCPU、CPUのですね、
355:40 性能こう一段階こう上げるような仕組みとかもあったりするので、まあ高負荷にもですね、 耐えられますよということを言うことができます。
355:52 で、このバースト機能とか、 まあそのCPUとかの性能こうちょっと上げるものになりますけども、
355:58 いわゆるこうスケーリングという策もございますね。 アジェイルはクラウドサービスですので、
356:04 まあ自動的にこうスケーリングするというところが得意になります。他にもですね、こう、 サーバレス系のサービスとかだったら、何もアクセスがない時には、
356:14 こうアイドル機関というふうになって。
356:17 コストも削減できますし、アクセスが増えてきたならば、あのサーバーを立ち上げて、 その時だけ対応するといったようなこともできます。まあ、様々な面でですね、こう。
356:27 性能に関してはアジェル上のリソースは機能を持っていますので、まあ、 そういったものをお伝えすると、
356:34 性能に関する懸念というものはどんどん解消されていくんじゃないかなと思います。はい。 こちらのセクションではですね、
356:42 性能に関する懸念とそれへの対応方法というものを学びました。
356:46 大きく七つほど表の方ではまとめておりましたので、ぜひですね、 細かく見ていただければと思います。では続いてですね、
356:56 移行に関する懸念を見ていきましょう。まあ、既存のシステムですね。 新しい環境で移すとなってきますと、なかなかこう不安が出てくるかと思います。
357:08 Azureという新しい環境ですね。 うまくやっていけるかなというふうに気になるかと思うんですけども、
357:14 まあそれに対する打ち手というものもアジェル上たくさん用意しております。まあ、 一番気にされるのが、この作業工数とか期間とかダウンタイムの部分になるかなと思います。
357:25 で、移行するときにはですね、Azure上はこう様々なサービスを用意しております。 例えばAzureマイグレートとかですね、
357:34 Azureデータベースマイグレーションサービス。
357:37 やっぱりもこう。SQLサーバー、マイグレーションアシスタントと呼ばれるような形で、 まあデータ移行ですね。まあ、スムーズにやってくるようなサービスがありますので、
357:47 まあ各あの移動させたいデータベースの種類とかに応じて、 適切な移行のサービスを使っていただければと思います。で、なかなかこう、
357:54 技術力が足らなくて、なかなか一向に踏み出せないなという場合だったら。
357:59 まあ、Microsoftラーンのサービスがございますので、 まあこちらでしっかりこう学習をしていただければ、
358:05 スキル不足のところも潰していくということができます。はい。以上ですね、 Azureの移行に関する懸念ところを説明しました。まあ、
358:13 データベースを移行するとなると、ちょっとこう怖いものがありますが、 その移行のところを支援するサービスはしっかりAzureとしては用意してますので、
358:22 まあそれをしっかり使っていきましょうということです。
358:28 ではそれで監視に関する懸念ところですね。こちらを説明したいと思います。まあ、 システムが複雑になってきますと、まあ、何か問題が起きた時に、
358:38 まあ原因がどこにあるかわからないなという場合があると思います。 特にアプリケーションとデータベースが密接に連携するシステムでしたら、
358:47 まあアプリ側に問題があるのか、データベース側に問題なのか、 それの切り分けが難しいという懸念があります。
358:56 で、このような問題に対するAzureの解決策というのが、 やはりここでも登場するAzureモニターになります。まあ、
359:03 Azureモニターを使いますと、まあアプリケーションとかですね。 データベースインフラ。まあ、様々なリソースに対して、
359:10 まあデータをちゃんとこうとってあげて、適切なサービスの方にこう転送してですね、 あの可視化をするということができるようになるわけです。なので、
359:19 問題の切り上げが難しいというところは、こういったAzureモニ。タ。 ーの機能とかを使えばなくなります
359:27 特にまあ、データベースではなくてですね。このアプリケーションという単位でしたら、 アプリケーションインサイズという分析機能があります。これを使いますと、
359:36 アプリケーションのパフォーマンスを包括的に監視することができますので、まあ、 このシステム全体のアプリケーションで、
359:43 まあどこがボトルネックになっているのかなとかは、 もう一目でビジュアル化されるものになります。
359:52 はい、以上ですね、監視に関する懸念という風になっておりました。まあ、 ここでもですね、Azureモニターというものが大活躍するんだよという話ですね。
360:03 ではですね、残り懸念としては大きく2種類となります。まず可用性の部分ですね。まあ、 システムが止まらないことというのが、ビジネスにおいては非常に大事な要件だと思います。
360:16 いわゆる高可用性。
360:18 取れるんですか？と。災害復旧は大丈夫なんですか？というところがまず一つ、 お客様としては気になる部分だと思います。で、こちらはですね、やはりこう、
360:29 アジルのこのクラウドの性質がすごい大活躍しまして、可用性ゾーンと、 こうリージョンという、こう概念ですね、
360:37 アジルの信頼性を支えているこの二つがしっかりですね。こう可用性と、 こちらのこの災害復旧、この二つを実現してくれています。
360:46 まあ簡単に言いますと、リソースというものを同じリージョン間でも、 そのアベイラビティゾーンゾーンで分けましょう。かつ、
360:54 別のリージョンにもレプリケーションとして配置しておきましょう。 こうすると可用性も保たれますし、災害に対しても強くなりますよね、という映画です。で、
361:03 こういったレプリケーションが簡単な操作でできるような仕組みを整えているという部分がAzureの強みになります。
361:13 はい、以上ですね。可用性に関する懸念のところは終了になります。可用性ゾーンですね。 あとこう、ジオリプリケーションといった機能もあったりしますので、まあ、
361:23 こういったところをお客様に提案することで、可用性に関する懸念をですね、 抑えていただければと思います。はい、最後ですね。
361:31 競合比較に関する懸念となりますここですね。 なかなか難しい部分もあるかと思いますが、
361:37 まあなぜAzureを選ぶのかということですね。
361:41 なぜAzureを使うべきなのかっていうところをお客様にこう訴求していく必要があるかと思います。Azureを選ぶ理由がちょっとまだわからないですというような懸念を持たれた場合には、ぜひですね、このMicrosoftの統合基盤としての価値、ここの部分を抑えてお伝えしていただければと思います。
362:02 まあ、Microsoftの統合基盤としてのこれはですね、 様々なシステムサービスというものをこう連携できるというのが、
362:10 もう圧倒的な強みと言えるかと思います。もうID基盤のところからですね。始まりまして、 このMicrosoftエントラIDを使えば、もうたった一つですね。
362:20 もう様々なサービスのシングルサインオンとかができるわけです。 分析系のサービスもありますし。
362:27 業務改善につながるようなMicrosoftパープラットフォームとかともシームレスに連携する。このように、いわゆるこうビジネス活動をしていくっていう形ですね。観点で、かつ今後のデータ活用とかAI活用という観点で、まあ必要なサービスとかをもう網羅だけに持っていて、かつそれがつながると簡単につながるような仕組みが整っている。そして利用するときに、MicrosoftエントラIDという一つの認証基盤で全部あのアクセスできると。まあ、そのような。
362:56 使い心地の良さというものが、 このMicrosoftのAzureの価値になると思います。そうですね。
363:04 このMicrosoftの統合基盤としての価値の部分をお客様のところに訴求しているっていうのが、まあ競合比較された時の一つの鬱になってくるかなというふうに思います。はい、以上がですね、今回の第七章オブジェクションハンドリングのところの内容となります。
363:25 表のところとかですね、結構いろいろ書いておりまして、 まあ懸念に関してはもうですね、もう数十個ぐらい入ってるかと思いますので、ぜひですね、
363:34 こうしたあの賞はまたお目を通していただいて、ああ、確かにこんな懸念あるな、 こういった時にはどういうふうに言ったらいいんだろうというようなですね、学びをですね、
363:44 この賞から得ていただければなというふうに思いますはい、ということですね。 第七章まで終了といたしましたので。
363:51 データベースの講座の内容は以上となりますはい。データベースのですね。 様々な内容を学んだかと思います。まあ、適材です。
364:03 適所なデータベース選択とデータ資産の利用に向けてということで、 第一章から第七章という内容を学んでおりました。まあ簡単にですね、
364:15 あのまとめていきますと、Azureにおいてはですね。まあ、様々な。
364:22 サービスというものがありますで、それをしっかりですね、 こう連携していくというのが大事にあります。で、連携していくことによってですね、
364:29 データの価値、そしてAI活用というところが、だんだんますますですね、 促進されていきますので、たった一つのサービスをお伝えするということではなく、こう、
364:38 ソリューション全体としてね、こう連携した、そのシステムでですね、 お客様にサービスの価値をこうお伝えしていくというのが非常に大事な点だと思います。
364:49 はい、それではですね、データベースの講座の内容は以上で終了となります。 皆さんですねえ、ちょっと長丁場の講座でいろいろなことを学んで結構ですね。
365:01 タフだったかと思いますが、いかがだったでしょうか。はい、残りですね。 約12分ほどありますが、クロージングというところで、締めの方にですね、
365:12 入ってきてればないければなというふうに思っております。
365:18 データバイスの方ですね、私の方で先ほど簡単にまとめさせていただきましたので、 セキュリティとですね、インフラに関して。簡単に
365:26 講師の入江の方からですね、少しまとめてまとめたメッセージをですね、 皆さんにお伝えいただければなというふうに思っております。では、入江さん、
365:35 お願いいたしますあはい皆様どうもお疲れ様でございましたでは、 私の方からですね、まあ、インフラとセキュリティに関して、
365:43 まあ簡単にですが総括させていただ。きます
365:46 インフラの方ではですね、まあ、 主にクラウドへの移行というトピックで様々な技術の概略を見てきました。まあ、
365:53 ポイントとして重要だと思うのはですね、 オンプレ廃止すべしという態度は取らないということですね。まあ、オンプレとかの、
366:00 まあ環境を両立するための考え方であるとか、 まあフレームワークソリューションもあります。ですので、まあコストも正しく計算しつつ、
366:08 まあ本当にお客様にとって価値を出せるのはどういう状況なんだろうというのを真実に考える。必要があるということです
366:15 で、まあ、それらを考え抜くことで、まあ、いわゆる顧客中心の、まあ提案に、 お客様中心の提案につながっていくんじゃないかなと思います。ただですね、
366:24 マックスの価値を考える中で、まあ、オンプレが持つ制約っていうのは、 まあやっぱり無視できないものかなと思います。講座でお話ししましたように、まあ、
366:32 オンプレはまあ制約があるために、まあ、 今自分たちが持っているものにできることをするという思考にどうしても陥りやすくなってしまいます。
366:40 ですので、まあそれをいかに取り払って、まあアプリ中心、 あるいはすべきこと中心主義みたいなものに持っていくか、大事かなと感じます。
366:49 そしてセキュリティの方ですね。セキュリティの方では、まあ、 このセキュリティはコストではなくて、まあ投資なんですよという考え方に触れつつ、
366:58 まあ様々な製品の概要を見てきました。
367:02 セキュリティ体制の。まあ、整備自体はですね、 まあ流行り廃りがそんなに目まぐるしくあるものではないので、まあ対応がまだなら、
367:10 もうすぐにでも対応開始すべきものかなと思います。まあその点で、まあ、 あらゆる組織にとって、まあ必要となるであろう内容、これをまあ、
367:19 ごく簡単に紹介できたんじゃないかなと思います。ただですね、まあ、 新しい技術の登場によって、
367:25 まあ新たな攻撃戦略は登場するといったことは今後もあるかなと思います。
367:29 最近であれば、まあ、生成AI、あるいはAIエージェントですね、 それがそれに相当します。まあ、今回の講座ではまあ取り上げなかったんですけども、まあ、
367:37 ディフェンダーフォークラウド、ああ、フォーAIであったり、まあ、 先月のMicrosoftイベントで発表されたエントのエージェントアイディーだったりと、まあ新しいものにもうまく対応するためのソリューション、まあ今後も出てくるかなと思います。ただですね。まあ、それでも基本となるのは、まあ、今回紹介した。よ。う。な基本的なソリューションの組み合わせかなと思います
367:57 ですので、まあぜひとも、ああ、その製品と、まあその利用場面っていうのはですね、まあ、 お客様どもども、認識してもらって、
368:05 まあ安全にビジネスを拡大できるという体制を作っていただきたいなと思っております。 では私からは以上です。はい、入江さん、ありがとうございました。はい、
368:16 それではですね、この後ですね、アンケートのご案内、資料のご案内、トレーニング、 コンテンツのご案内というところをですね、続けさせていただきたいと思います。
368:27 まず皆さん、今回ですね、ご参加いただきまして誠にありがとうございました。 非常に長丁場な講座でしたが、まあセキュリティインフラデータベースと、
368:37 あの包括的にですね、様々なことを学べたのではないかなと思います。 ぜひこちらのURLよりトレーニングの感想の方をお聞かせいただければと思います。
368:48 こちらのアンケートですね。ご回答の方、どうぞご協力よろしくお願いいたします。
368:57 こちら講座のですね。冒頭の方でも説明をいたしましたが、 この資料のURLの部分ですね。こちらがあの資料をダウンロードする場所でございます。
369:08 はい、こちらですね。
369:11 で、今回の講座なんですけども、資料に対応した動画コンテンツもございますので、 こちらもですね、ぜひ学習の方お願いいたします。だいたいこう、トータルでこう、
369:22 9時間ぐらいあるような講座になります。こう、9時間半ぐらいですね、ありますので、 まあ前、ちょっとですね、こちらの学習を通じまして、このインフラ、
369:32 データベースセキュリティですね、こう詳しくなっていただければなと思います。
369:38 で、動画ファイルに関しまして同じ内容がですね。 まずユーチューブの方ですね。こちらもアップロードされますので、
369:46 こちらでも学習いただくことができます。まあ、 詳細版と言っておりますのがこの動画コンテンツですね。この長い方です。
369:53 9時間半のものになりまして、 まあ要約版っていうのが今回のあのライブ配信講座のことになります。
369:59 こちらのユーアールエルからですね。
370:04 動画サイトの方、今ユーチューブになりますけど、そちらの方を閲覧いただいて、 また改めて学習をしていただくということが可能でございます。ぜひ今後の学びですね、
370:14 ご活用いただければなというふうに思います。で、さらにですね、まあ、 今回の学習を通じて、まあもっとですね、インフラとかセキュリティとか、
370:23 データベースですね。まあ、しっかりこう学んでいきたいと。 さらに詳しくなっていきたいという方ございましたら。
370:30 ぜひですね、さらにこう、学びの方を深めていただければと思います。まずこう、 Microsoft learnの方にですね、えっと、
370:38 様々な学習コンテンツがございますので、そちらの方をですね、確認してみてください。 アセルの方ですと、まあ、資格試験というものがございます。で、
370:46 そちらの資格試験ですと、やはりこう、なんか目標というものもできますので、 じゃあそのまあ、合格がすること自体が目的ではないですけども、まあ合格を
370:55 目指してですね、学習してみようと。もう包括的にですね。
370:59 知識を学んでみようということを増やしていただくとよいかなと思います。はい。まあ、 例えばこちら、
371:04 MicrosoftサーティファイドAzureネタファンダーベンタルズとかになりますと、MicrosoftAzureデータサービスに関する知識ですので、まあ、これの内容が理解できていれば、まあAzureに関するですね。まあ、基本的なサービスのところは渡りして入ってるよというようなことになるかと思います。で、セキュリティとかですね。コンプライアン。ス。に関す。る初級の内容もありますしえ、え、まあ、中級と少しちょっとレベルの高めのところはあ、る
371:29 資格試験とかありまして、 Microsoft
371:31 certifiedアジエルレーダーエンジニアソシエイトとかですね。 アジュエルセキュリティエンジニアアソシエイトといったような資格試験もありますので、
371:40 ぜひですね、この中身ですね。まずこうカリキュラムのところとか見ていただいて、 まあ確かにこれはお客様の提案的にいうような知識だというふうに感じましたら、
371:49 ぜひ内容を学習していただければと思います。え、え、弊社の講座となりますが、 弊社の方でもですね、あのスキルアップAIという。
371:58 教育コンテンツでございますが、あのMicrosoft、 Azure AI 900対応ですね。AI 900対応、
372:05 クラウドAIサービス活用講座といったものとかですね。 AI
372:09 102の宿泊試験で対応したようなクラウドAIソリューション実践講座といったものを出しております。また、Azureにこだわらずですね。まあAIプランニングとか。
372:19 AIプロジェクト推進全般を学べるような講座とかも入っておりますので、 ぜひご興味ありましたらあのサイトの方ですね。見ていただければと思います。はい。
372:31 ではですね、事務的な連絡としてはですね、最後、これら三つとなりますはい。 今回の講座でございますが、Azureにおけるインフラ、セキュリティ、
372:44 データベースのところをしっかり皆さん学んでいけたかなというふうに思いますAI活用のためには。
372:51 AI以外の要素も必要ですよというところ。これ、相当なところに戻っていき、 戻っていきますが、これら三つがあってこそのAI活用というものになります。まあ、
373:03 どれが欠けてもですね、うまくいかないはずなんです。なので、この三つの内容ですね、 しっかり押さえていただいてですね、このAI活用、そしてデータ活用という観点で、
373:14 お客様に価値のある提案をですね、していただけますと幸いでございます。
373:20 Azureという大きなプラットフォーム全体でお客様のデータを守っていって、 その価値を最大化するということが。
373:28 これら三つを組み合わせることができるかと思います。本日学びました皆様、 本日学びました知識がですね、今後の皆様の活動において、
373:37 お客様の課題を解決するための一度となりましたら非常に幸いでございます。はい、 それではですね、これで講座の方を終了したいと思います。本日は皆さん、
373:47 誠にありがとうございました。
