AWS Well-Architected Partner Virtual Bootcamp に参加してきました
先日、12/22 に行われたAWS Well-Architected Partner Virtual Bootcamp に参加してきました。
これはAPNパートナー向けにWell-Archtected のワークショップをオンラインで行うというものです。 Well-Architected Framework は以下のリンクからアクセスできます（言語設定を英語にするとSaaSレンズが確認できます）。
今まではAPNパートナー向けに開催するケースはそこまで多くなく、2回目（かつオンラインでは初）の試みだったようです。
他社の方とワークショップを行う機会はなかなかなく、良かったのでそのレポートです。
ワークショップの流れ
一週間くらい前に事前に登録を行い、参加しました。 前日に、当日利用する資料が届き、当日はAmazon chime でワークショップが行われました。
当日は次のようなスケジュールで進行されました。
| 時間 | 内容 |
|---|---|
| 10:00 ~ 11:50 | Well-Architected フレームワークについてのおさらい |
| 11:50 ~ 13:00 | ワークショップの題材となる資料の読み込み、お昼休憩 |
| 13:00 ~ 14:25 | 運用上の優秀性の柱の説明とグループディスカッション＆発表 |
| 14:30 ~ 15:35 | セキュリティの柱の説明とグループディスカッション＆発表 |
| 15:45 ~ 16:40 | 信頼性の柱の説明とグループディスカッション＆発表 |
| 16:45 ~ 17:30 | パフォーマンス効率の柱の説明とグループディスカッション＆発表 |
| 17:30 ~ 18:00 | コスト最適化の柱の説明とグループディスカッション＆発表 |
内容
午前中
Well-Architected フレームワークの起こりからどのようにLens の観点が増えていったといった説明から Well-Architected の概要について学んでいきました。
以下の話が印象に残りました。
- well-architected が開始したのは2012年
2015年にframework を公開した。このタイミングでは4つの柱だった。 2016年に運用上の優秀性の柱が追加された - Well-Architected Framework(W-A)とは、
システム設計・運用の”大局的な”考え方とベストプラクティス集 - Well Architected Frameworkはチェックリストではない
情報を提供しているだけで、ユーザは理解したうえで活用して行く必要があります。 ベストプラクティスを知った上で、「ビジネス的な判断をする」ための手法。リスクや改善点の”顕在化”を目的にしている - Well-Architected フレームワークによるレビューはAWS による監査ではない
- レビューは一日や数時間で終わるもの（数日かかるようなものは何かがおかしい）。短時間で効率的にディスカッションを行う。
- 一回限りではなく、定期的にチェックを行って、継続的に改善していく
- 後で変更が困難な一方通行のドアのような変更を避けるために、初期の段階でレビューしていく
- 新しい機能の追加や本番の運用にのったときなどのライフサイクルに変更が出たタイミングで継続的に行うのが良い
- どの段階でどのように利用していくのがよいか
- 設計前の段階でホワイトペーパーを読む
- 100ページくらいあるので大変なので、少なくとも質問は読んでおく
- 定期的な見直し
- 要件検討（ホワイトペーパーを活用）
- 設計段階
- リリース前
- 運用フェーズ
- 設計前の段階でホワイトペーパーを読む
- 悪い決断をしてしまった場合は？
-> 継続的な改善プロセスの途中となり、決定とみなされない - クラウド向けの設計をするためには
Well-Architected Labs というページで実際にベストプラクティスをハンズオン形式で学ぶことができるとの紹介もありました。柱ごとに100・200・300といったようにレベルが設定してあるので、とっつきやすいと思いました。
お昼休憩の時間では少し長めに休憩を取り、資料の読み込みも行いました。 資料は午後からディスカッションを行うための仮想顧客のアーキテクチャを説明したものです。 この資料を基に午後のディスカッションが進行していきます。
午後
午後からはグループに分かれてディスカッションを行いました。
トピック1
1つ目のトピックは運用上の優秀性の柱でした。
設計原則は次の5つです。
- 運用をコードとして実行する
- 小規模かつ可逆的な変更を頻繁に行う（定期的なデプロイ）
- 運用手順を定期的に改善する
- 障害を予想する
- 運用上のすべての障害から学ぶ
これらの説明を10分程度で解説してもらい、各グループに分かれて20分程度ディスカッションをするという形式で行われていきました。 3,4 名で一つのグループなり、考慮事項の一つのトピックに焦点を当ててディスカッションを行っていく形です。 資料の説明では漠然としていて、（実業務で出くわすような）ざっくりとしていて情報が欠落しているため、様々な角度から議論できるようになっている題材でした。
トピック2
2つ目のトピックはセキュリティの柱でした。
設計原則は次の7つです。
- 強力なアイデンティティの基盤を導入
- 最小権限の原則
- ID管理を一元化
- トレーサビリティの実現
- 誰がどの変更を実施したのか、個人を特定できる形で後から変更点がわかるようにしておく
- 必要な情報を収集しておいて、自動的に分析やそれをトリガーになにかするようにする
- 全レイヤーにセキュリティを適用する
- 深層防御のアプローチ
- セキュリティのベストプラクティスを自動化
- 伝送中のデータと保管中のデータの保護
- リスク評価を行い、必要に応じて暗号化
- データに人を近づけない
- 人をシステムやデータから遠ざける仕組みを構築する
- セキュリティイベントに備える
- 組織の要件に合わせてインシデントタイムシュミレーションを行っておく
- Game Day を行う
セキュリティイベントを把握するのがまず大事でそのあとに分析を行っていく必要があるという話もありました。 SIEM(Security Information and Event Management) を行うAWSのソリューション（SIEM on Amazon Elasticsearch Service）は初めて知りました。
AWSではコンピューティングリソースを保護するマネージドサービスがないので、DeepSecurity などを入れている企業も多いという話を伺いました。 GuardDuty での検知（発見的統制）はあるので、発見後に封じ込めることが必要であるという話もディスカッション中に出てきました。
GuardDuty（脅威検出） や Detective（インシデント調査）、Macie（機密情報の検出・保護）などのサービスはあるので、レビューをしていくうえで足りない部分をサードパーティ製のソリューションで補うのがよいのではと考えました。
トピック3
3つ目のトピックは信頼性の柱でした。
一言でいうと、「期待されるタイミングで、意図した機能を正確かつ一貫して実行するワークロードの能力（ライフサイクル全体を通してワークロードを運用及びテストする機能が含む）」です。
設計原則は次の5つです。
- 障害からの復旧を自動化する
- 閾値ベースで復旧（slack通知やトリガー）
- 復旧手順をテストする
- 本番相当の環境で障害を起こしてテストできる
- システム全体の可用性を向上させるために水平方向にスケールする
- キャパシティの判断を勘に頼らない
- 計測する
- 常に最適なリソースを用意する
- オートメーションで変更を管理する
- IaCで管理できる(CloudFormation, AWS-CDK)
- 人の手ではなく環境を立てることができ、ヒューマンエラーを排除できる
トピック4
4つ目のトピックは信頼性の柱でした。
一言でいうのと、「システムの要件を満たすためにコンピューティングリソースを効率的に使用し、要求の変化とテクノロジーの進化に対してもその効率性を維持する能力」のことです。
設計原則は次の5つです。
- 最新のテクノロジーを標準化する
- 新しいサービスが出てくるので、その時にあった選択をする
- わずか数分でグローバル展開する
- サーバレスアーキテクチャを使用する
- より頻繁に実験する
- IaC で簡単に環境を立てて実験できるようになっている
- システムに対する精通の程度を考慮する
また「昔のアンチパターンが時ともに変化する。定期的なレビューにより、時代に合った選択を行いパフォーマンスを維持する」という話もあり、 Lambda + RDS のアンチパターンがそうではなくなった話を思い出しました。
トピック5
最後のトピックは信頼性の柱でした。
設計原則は次の5つです。
- クラウド財務管理の実装
- 消費モデルを導入する
- 全体的な効率を測定する
- 差別化につながらない交付かの作業に費用をかけるのを病める
- 費用を分析し、帰属させる
感想
（意図的に）色々な突っ込みどころを持ったアーキテクチャや概要説明であったので、グループメンバとのディスカッションを広がりを持ってやることができてとても有意義でした。
3つ目のトピックくらいから疲れてきましたが、他社さんの話や自分の中になかった考え方を知れて勉強になりました。
CommentScreen に匿名でメッセージを投稿できて、SAの方にほとんど拾っていただけたので、ざっくばらんな内容のメッセージも投稿できたのがよかったです（「やりたいけど、できてないです」というのは匿名だといいやすかったです）。
また、ディスカッション中にもSAの方がファシリテートしてくれたので短い時間でしたが活発に議論できて、あっという間にワークの時間が過ぎていきました。
内容が良かったので、次回があったら同僚にようと思います。
Well-Architected tool も実業務で同僚が使っているのを見たことしかなかったので、今度自分で触る機会を作ってみようと思いました。
AWS DevOpsエンジニア（DOP） と セキュリティ（SCS）に合格しました
前回の試験から間が空いてしまいましたが、あの後2週間おきに立て続けにDOPとSCSを受験してきました。
DevOps エンジニア
事前準備
前回終了時にはもう少しLambda やAPI Gateway の実装寄りの経験が必要なのではと思っていましたが、試験範囲としては SysOps Administrator と Developer Associate の範囲ということもあり追加で勉強をして、試験に臨んでみました。
DVAの方である程度勉強していたのと、業務でCode シリーズを触る（ある程度知っておいた方が人に説明する際の紋所になって仕事がしやすくなる）ため、資格を取得しておいた方がいいと思ったということもあります。
試験勉強としては、模擬試験をバウチャーを利用して受験、その後全問見直しと理解をしていくというスタイルで臨みました。また、Codeシリーズがテスト範囲としてあり、あまり理解が進んでいなかったので、実際に手を動かしてパイプラインを作成してみました。
試験当日
コロナで東京には行きにくくなってしまったので、車で行ける範囲を選択しました。
厚手のマスクを着用していったら途中で意識が朦朧としてきてテストの問題が大変だったというより酸素を確保するのが大変でした。
全問解き終わったのが残り10分くらいで軽く見直しをしてタイムアップ。結果は844点である程度余裕をもって合格できました。
問題文が何を一番問うているのかと、勝手に文脈を補わないという点が自分なりのコツでした。
セキュリティスペシャリティ
事前準備
試験範囲内のことはSAPとDOPの試験内容で補えると考え、また「要点整理から攻略する『AWS認定 セキュリティ-専門知識』 」 という書籍も評価がよかったのでこちらを利用して勉強をしながら、対策を進めました。
内容としては関連するAWS のサービスがまとめられていて、巻末には練習問題がありました。
AWSの模擬試験を受験してみて7割とれていたので、復習と書籍を利用すれば合格できると踏みました。
試験当日
毎回試験は月曜日の10:30 から受けるようにしています。週末に勉強をして、平日の人があまりいない時間に試験を受けるという算段です（ここ二か月毎回同じ時間に試験を受けに来ているので顔を覚えられてしまった可能性があるかもしれません）。
試験の問題自体は170分で65問なので、プロフェッショナル試験よりも時間に余裕がありました。
30分くらい残して全問解ききり、フラグを付けたところを見直しました。
肌感としては800点くらいは取れたのではと思いましたが、結果は762点。あと一問間違えていたら落ちていました。
オンプレADとのインテグレーションやIAMとリソースのアクセスコントロールの優先順位が詳細までわかっていないなど、知識の粗が目立つ感じでした。
雑感
これで5冠+1 になりました。
ただ、試験内容はAWS以外の部分でも利用できる箇所はありますが、AWSなしでどうするかであったり、実戦経験はまだまだひよっこなのでこれからも学び続けていきたいと思います。
AWS ソリューションアーキテクト - プロフェッショナルに合格しました
AWS ソリューションアーキテクト - プロフェッショナルに合格しました
SAP試験に合格しました。1月くらいからちょっとずつ勉強してきて、今月やっと受かったのでどんなことをしてきたのか書き残したいと思います。
やったこと
まず自分の立ち位置を知るためにAWSの模擬試験を受けてみました。結果は6割程度。もう少し勉強すれば行けるかなと思いました。その後試験範囲のBlackBelt を全て読みました。ぱっと読めば頭に入るタイプではないので、過去の記事のようにそれぞれのサービスの説明を書きながら整理していきました。
その後、Udemy のコースを購入して演習テストを解いて、解説を読みつつ知識を補強していきました。
内容は、本番試験に比べてマニアックなものが多く、個人的には2回りくらい難しかったような気がします。全5回の演習を終えても7割はおろか、6割を超えることもできず、かなり凹みました。（一周に3H+4H くらいかかっているのに点数が全く伸びませんでした）。
こちらのコースを全て終えて、点数が思ったようにならなかったので、気分を変えるために（点数がある程度出て自信をつけるために）こちらの対策本を購入してやってみました。
模擬試験をやってみたところ7割以上、合格点未満という結果でした。しかし、問題の難易度としては本番にかなり近いと思います。
こちらの問題と振り返りをして、さらに最初に受けたAWSの模擬試験の間違えた問題を振り返りました。ここでの振り返りはノートに書き込んでいく古典的なスタイルで勉強していました。
一通りできることはやり尽くした感があり、点数が足りている訳ではないですが、ここで一回受けてみようということで受けてみました。
申し込みと本番
電車ではなく、車で行ける試験会場を選びました。
自分の一番の不安は3時間、トイレに行けず、冷房にあたり続けることだったので、当日はパーカーを持参して、最低限の水分をとって臨みました。
試験官に聞いたところ、途中でトイレに行くことはできるみたいですが、試験時間は進むとのことでした。
徐々に体温が奪われていきましたがなんとか3時間耐えることができました。
試験自体は1時間で25問を解くペースで進めないと間に合わないのですが、少し遅れ気味で、最後の問題を解き終わった時には残り10分程度しかありませんでした。問題文が何を聞いているのか（もっともスケールする、であったり、コスト最適化など）によって答えが変わってくるので普段以上に注意しながら読んでいったため、時間に追われることになりました。
試験問題は演習問題でやってきた問題より日本語が怪しく、英語版を読みつつ回答していきました。
結果
試験の詳細の点数なども当日中に返ってきました。8.5 割くらいの得点で合格することができました。
他の人に比べて時間はかかってしまいましたが、合格できてよかったです。
SAP-C01 合格したー
— あさぎ (@_athagi) 2020年9月7日
後日談
SAPに合格した流れでDVAにも受験してきました。前日にバウチャーを利用して模擬試験を受けたところ55点だったので危ういなと思いました。問題の間違った箇所を重点的に見直しをして、当日臨みました。あまり手応えはなく、慢心してしまったかと思い、後悔していましたが9割程度の得点で合格できていました。問題文の日本語訳は結構ひどく、問題文の一番重要な部分が丸ごと抜け落ちているというものもありました。
振り返り
Associateレベルは制覇して、残すはDevOps となりました。DVAは合格はできたものの知らないことが多く、運がよかっただけな気がするので、実際に何かものを作ってそのあとに試験を受けるのがいいのかなと思いました。
AWS Amplify
# AWS Amplify
https://d1.awsstatic.com/webinars/jp/pdf/services/20200520_AWSBlackBelt_Amplify_A.pdf
## AWS Amplify とは
- Web フロントエンド 、モバイルアプリの開発を加速させるために作られたプラットフォーム
- AWS を用いたサーバーレスなバックエンドの構築をするためのCLIやバックエンドと接続するためのクライアントライブラリ、Web サイトのホスティングの仕組みを持つ
- Amplify CLIを用いることで、他のAWSサービスとの連携部分を含めて操作、連携が可能
- Amplify で解決されること
- Amplify Framework と呼ばれる、バックエンドに直感的なインターフェースで接続できるライブラリ
## Amplify を使ったアプリケーション開発
- 準備
- Amplify CLI を用いたバックエンドの構築
- npm でAmplify Framework をインストールする
- Amplify CLI で作成された設定ファイルを読み込むと利用できる
- Amplify Framework を用いたアプリケーションの実装
- Analytics
- ユーザーのセッションや属性などの計測
- API
- REST/GraphQL API の利用
- データソースに利用できるもの
- Amazon DynamoDB
- Amazon Elasticsearch Service
- Amazon Aurora Serverless
- AWS Lambda
- REST API
- スキーマ設定を schema.graphql に記述しておく
- Authentication
- 認証APIと pre-build UI component
- Amazon Cognito との統合
- アプリケーションに統合・認可・フェデレーション機能を簡単に実装可能
- 認証用のUIコンポーネントが提供されており、UIタグを配置するだけで、サインイン、サインアップ、パスワード復旧機能が実装されたコンポーネントを実装可能
- Storage
- Static content のシンプルな管理
- Interactions
- Deep Learning を利用したBot
- PubSub
- リアルタイムなデータのやり取り
- Notification
- キャンペーンや分析機能を持ったプッシュ通知
- Predictions
- AI/ML コンテンツの組み込み
- テキスト翻訳、文字読み上げ、Object Detection、文章のネガポジ判定といった機能が簡単に実装できる
- 対応するAWSサービス
- XR
- AR/VR コンテンツの組み込み
- アプリケーションのデプロイ
## 直近のアップデート
- Amplify Datastore
- 概要
- デバイス側のストレージエンジン
- オンライン・オフラインを気にすることなく実装可能
- 3種類の競合検知のオプション
- Auto Merge
- データの競合を検知すると自動的にマージを試みる
- Optimistic Concurrency
- データの競合を検知した場合、マージを実施せずクライアントからのリクエストを拒否する
- Custom Lambda
- データの競合を検知した際に独自に定義したAWS Lambda を起動する
- Amplify Datastore API
- 更新
- 削除
- 参照
- 購読
- Amplify iOS / Amplify Android（2020.05.27にGA https://aws.amazon.com/jp/about-aws/whats-new/2020/05/announcing-general-availability-amplify-ios-android-authentication-data-ai-ml-support/）
## よくあるケース
- 複数の環境（prod, stagingなど）を利用したい
- Amplify Console を利用した複数環境のデプロイ
- Multiple Environment による環境構築と接続先の切り替え
- Branch とバックエンドを紐づけることで、環境ごとのCI/CDパイプラインの構築が可能
- Amplify CLI に対応していないバックエンドの構築
- 任意のCloudFormation テンプレートをカスタムカテゴリとして定義できる
## 雑感
AWSのWebフロントエンド 、モバイルアプリの開発を加速させるプラットフォーム。連携部分や、モバイル特有の部分をAmplify が行ってくれることで、価値のある部分に集中することができる。
複数環境の構築やそれを利用したテストまではカバーされている。対応していない部分はCloudFormation を記述することでカスタムカテゴリとして利用できるようになるみたいだが、用法用量は守ったほうが良さそう。
Amazon Pinpoint
# Amazon Pinpoint
https://d1.awsstatic.com/webinars/jp/pdf/services/20171109_AWS-BlackBelt-pinpoint.pdf
## グロースハックとは
- 概要
- データからKGI、KPIを定め、施策を打ち、振り返りを繰り返す
- 顧客価値の最大化（プロダクトの改善）と事業の成長にフォーカスする
- 代表的なフレームワーク AARRR!
- Acquisition : 獲得
- 新規ユーザーがどこから流入するか
- Activation : 活性化
- その中で何％がハッピーな体験をしたか
- Retention : 継続
- 彼らはまたサービスに戻ってきてくれるか
- Referral : 紹介
- 彼らはサービスを友達に紹介してくれるか
- Revenue : 収益
- このサービスで収入は得られるか
- AARRR!の課題
- ユーザー体験の価値最大化という視点がないので、部分最適に陥ってしまいがち
- ユーザー価値を最大化するために
- 適切なエンゲージメントとそこに至る課題
- タイミング
- どうやって適切なタイミングを知るか
- ターゲット
- 対象をどう抽出するのか
- 内容
- メッセージをどう最適かするのか
- 結果
- どうだったか
- これらの課題にAmazon Pinpoint で立ち向かう
## Amazon Pinpoint とは
- できること
- ユーザ行動の解析とかしか
- ターゲッティング通知配信
- プッシュ、Email、SMS
- 以前はDBとWorker + SNS でデータを抽出してターゲッティングが必要だった
- 配信数、開封率等の把握
- イベントトラッキングと可視化
- 主な機能
- キャンペーン
- 条件指定した（動的）セグメントとインポートした（静的）セグメント
- S3からファイルをインポート
- 利用状況や標準属性から絞り込み
- 配信チャネル
- モバイルプッシュ
- SMS
- 配信チャネル別の分析
- スケジューリング
- 即時配信
- 予約配信
- 繰り返し配信
- A/Bテスティング
- メッセージのA/Bテスト
- 最大5つのメッセージを作成し、どれだけの割合で送るかを決められる。それを分析できる
- スケジュールのA/Bテスト
- 利用状況・イベントのトラッキングとストリーム
- SDKを利用することで容易に
- イベントベースのファネル分析も可能（LP閲覧まで行った、住所入力まで行った、内容確認まで行った、購入ボタンをクリックするところまで行った）
- イベント情報をKinesis Streams, S3へ
- データの再利用性を高める
- 分析基盤の拡張性を高める
- ダイレクトメッセージ
- プロジェクトのオプション
- 送信速度の調整などができる
- 1日にユーザが受け取るメッセージの最大数
- キャンペーン当たりの最大メッセージ数
- 配信除外時間
- 単位の変換
## Amazon Pinopint の運用パターン
- 属性ベースのセグメントパターン
- 条件によってメッセージを送信する対象を決める
- セグメントインポートパターン
- Athena やRDSに入っている個人データからターゲットを抽出しS3に保存。そのファイルをAmazon Pinpoint にインポートして利用
- 静的なデータ
- 速報パターン vs 非速報パターン
- 速報パターンだと、ユーザーが一斉にサイトに訪れる可能性があるのでページのサーバが大量の一斉アクセスに耐えられるようになっていないといけない
- 非速報パターンではユーザーは徐々に訪れるのでAutoScaling でも耐えられる
## さらに高度な分析
- Amazon EMR や AWS Glue を利用したETL処理
- Amazon Athena 、Amazon Redshift、Amazon EMR を利用した分析
- Amazon QuickSight を利用したBI、可視化
- リアルタイムダッシュボードとしてAmazon ES(Kibana) を利用
- リアルタイムダッシュボードにPinpoint の情報も統合
## 雑感
Amazon のMobile push & 分析のマネージドサービス。基本的にはAmazon SNS Mobile Push を利用するよりこちらを利用することを推奨している。面白かったのは速報＆非速報パターン。Pinpoint がサーバレスでスケールするので一斉に送りたくなってしまうが、そうすると一斉に大量のユーザーが流れ込んでしまうのでアプリの設計次第ではサーバが落ちてしまいかねない。そういう時に非速報パターンでユーザの動きを制御することで大量のユーザにキャンペーンを流しつつも、サーバーがダウンして体験を損なわないということができる。
A/Bテストなどの実験しやすい機能も揃っていて、どんな時にユーザーの反応がいいかを試せるのはかなりいい機能だと思った。
Amazon QuickSight
# Amazon QuickSight
https://d1.awsstatic.com/webinars/jp/pdf/services/20200204_AWS_BlackBelt_QuickSight_Update.pdf
## Amazon QuickSight の特徴
- 特徴
- 用語
- フィールドリスト
- RDBでいう列の一覧
- ディメンジョン
- グルーピングの軸
- ビジュアル
- グラフ
- 分析
- 複数のビジュアルを組み合わせて作成
- SPICE
- QucickSight のユーザー
## ML インサイト
## 埋め込み
## カスタマイズ
- テーマ
- UIのカスタマイズが可能
- グラフのカスタマイズも可能
- 条件付き書式
- ワンクリックフィルタ
- モバイルアプリ用の機能
## データ操作の改善
- クロスソースジョイン
- 複数のデータソースにまたがったジョインを実現
- 結果セットがSPICEに格納されるため、複数データソースを利用する際はデータ量に注意が必要
- アクセスコントロール
- IAM ポリシーや QuickSight ユーザ/グループに紐づけられる
- S3, Athena, RDS, Redshift に対応
- Amazon Athena Workgroup サポート
- レベル対応の集計
- 表示時点の集計とは別に集計を行うkん吸う
- E.g. 顧客の売り上げ合計が100000以下は集計しない
## 雑感
AWS のマネージド、サーバレスBIサービス。
管理者/分析者とReader(結果の利用者) に分かれて利用される。
分析の際にはSPICE というインメモリデータベースでデータの分析が行われるがデータ量に気をつけないといけない。またReader の人数ベースで課金が発生するので運用の設計はきちんとしておかないと結構お金がかかるように感じた。
BIツールであるので、特定の人に公開されたWebサイトでグラフィカルにカスタマイズされたUIを提供するのが主といった感じ。
AWS Glue
# AWS Glue
https://d1.awsstatic.com/webinars/jp/pdf/services/20190806_AWS-BlackBelt_Glue.pdf
## データ分析
- プロセス
- 収集
- 保存
- 過去では、データ収集の際にETL処理を行い、分析しやすい状態にしていた
- 現在では、データレイクに生データをそのまま保存し、分析する前に前処理を実施している
- 分析
- 活用
- AWS Glueとは
- 様々なデータソースのメタデータを管理する、フルマネージドでサーバーレスなETLサービス
- 特徴
- 構成要素
- データカタログ
- Apache Hive メタストア互換のメタデータリポジトリ
- 実データとは別に表の定義だけ格納する仕組み
- 実データはHDFSやS3などに保存する
- 複数のデータソース
- メタデータをRedshift, Athena, EMR と連携可能
- クローラー
- スキーマ管理
- 接続管理
- データをクロールする際のアクセス方法
- S3
- DynamoDB
- JDBC
- サーバレスエンジン
- ジョブ
- Worker Type
- Glue 内のSpark ジョブに割り当てるワーカーのタイプを変更可能に
- DPU という単位(4vCPU, 16GB)
- DynamocFrame
- SparkSQL DataFrame と似たGlue特有の抽象化の概念
- ETLに特化している
- DynamicFrame はデータ全体を表し、DynamicRecord はデータ一行を表す
- DataFrame と DynamicFrame 間でそれぞれ変換することができる
- Choice 型
- ブックマーク機能
- ジョブの実行状態を保持する機能
- サーバーレスETL処理の使い分け
- 独自ライブラリの利用
- スケジューリング
- ワークフロー作成機能
## 開発
- ETLジョブのコードを開発・実行する環境
- SageMaker Notebook
## ネットワーク・セキュリティ・監視
- Glue からVPC Endpoint 経由で他のサービスにアクセス
- Glue からVPC Endpoint 経由でVPC Peering を通して他のVPCリソースへアクセス
- セキュリティグループ
- Glue 内のアクセス許可
- Glue 内で管理するアクセスポリシー
- データカタログリソースへのアクセス制御
- データカタログに対するクロスアカウント・クロスリージョンのアクセス制御
- 暗号化
- データカタログ、接続パスワードのKMSを利用した暗号化
- モニタリング
## ユースケース
- データカタログを用いたメタデータ管理
- EMR/Athena/Redshift Spectrum を利用する際のメタデータ管理に利用
- ジョブによるSQLの定期実行
- トリガー・Python Shell を用いてRedshift に定期クエリを実行し、データの加工を行う
- WorkFlow 機能を用いたETLパイプライン
- WorkFlow 機能を用いて単一ジョブではなく、複数ジョブを組み合わせて実行する
- サーバーレスアナリティクス
- Glueのデータカタログを利用する
- SparkSQL を用いて標準SQLでSageMaker Notebook を用いて分析を行う
- データレイクを用いたログ分析基盤
- スピードレイヤ・バッチレイヤを活用したログ分析基盤
- アーキテクチャ
- Glue とSageMaker を用いた機械学習基盤
- Glue WorkFlow を利用したETL・機械学習のワークフロー
## まとめ
## 雑感
機械学習や分析をする際にデータレイクのデータはそのままでは利用できない。それを可能にするためにデータカタログを作成する必要がある。Glue はETL処理を行い、他のAWSサービスが分析をできるようにするサービス。
ただ、これだと部分的にしかできずに他のサービスのセットアップも必要になる。そこでAWS LakeFormation がある。
課金はETL処理をするためのリソースと各種サービスの料金がかかる。
