AWS ソリューションアーキテクト - プロフェッショナルに合格しました

AWS ソリューションアーキテクト - プロフェッショナルに合格しました

SAP試験に合格しました。1月くらいからちょっとずつ勉強してきて、今月やっと受かったのでどんなことをしてきたのか書き残したいと思います。

 

やったこと

まず自分の立ち位置を知るためにAWSの模擬試験を受けてみました。結果は6割程度。もう少し勉強すれば行けるかなと思いました。その後試験範囲のBlackBelt を全て読みました。ぱっと読めば頭に入るタイプではないので、過去の記事のようにそれぞれのサービスの説明を書きながら整理していきました。

その後、Udemy のコースを購入して演習テストを解いて、解説を読みつつ知識を補強していきました。

www.udemy.com

内容は、本番試験に比べてマニアックなものが多く、個人的には2回りくらい難しかったような気がします。全5回の演習を終えても7割はおろか、6割を超えることもできず、かなり凹みました。(一周に3H+4H くらいかかっているのに点数が全く伸びませんでした)。

こちらのコースを全て終えて、点数が思ったようにならなかったので、気分を変えるために(点数がある程度出て自信をつけるために)こちらの対策本を購入してやってみました。

www.amazon.co.jp

模擬試験をやってみたところ7割以上、合格点未満という結果でした。しかし、問題の難易度としては本番にかなり近いと思います。

こちらの問題と振り返りをして、さらに最初に受けたAWSの模擬試験の間違えた問題を振り返りました。ここでの振り返りはノートに書き込んでいく古典的なスタイルで勉強していました。

一通りできることはやり尽くした感があり、点数が足りている訳ではないですが、ここで一回受けてみようということで受けてみました。

 

申し込みと本番

電車ではなく、車で行ける試験会場を選びました。

自分の一番の不安は3時間、トイレに行けず、冷房にあたり続けることだったので、当日はパーカーを持参して、最低限の水分をとって臨みました。

試験官に聞いたところ、途中でトイレに行くことはできるみたいですが、試験時間は進むとのことでした。

徐々に体温が奪われていきましたがなんとか3時間耐えることができました。

試験自体は1時間で25問を解くペースで進めないと間に合わないのですが、少し遅れ気味で、最後の問題を解き終わった時には残り10分程度しかありませんでした。問題文が何を聞いているのか(もっともスケールする、であったり、コスト最適化など)によって答えが変わってくるので普段以上に注意しながら読んでいったため、時間に追われることになりました。

試験問題は演習問題でやってきた問題より日本語が怪しく、英語版を読みつつ回答していきました。

 

結果

試験の詳細の点数なども当日中に返ってきました。8.5 割くらいの得点で合格することができました。

www.youracclaim.com

他の人に比べて時間はかかってしまいましたが、合格できてよかったです。

 

 

後日談

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 を使ったアプリケーション開発

  1. 準備
    • npm Amplify CLI をインストール
    • CLI の初期設定
    • 設定を作成して、push することで適用される
  2. Amplify CLI を用いたバックエンドの構築
    • npm Amplify Framework をインストールする
    • Amplify CLI で作成された設定ファイルを読み込むと利用できる
  3. Amplify Framework を用いたアプリケーションの実装
      • Analytics
        • ユーザーのセッションや属性などの計測
      • API
      • Authentication
        • 認証API pre-build UI component
        • Amazon Cognito との統合
          • アプリケーションに統合・認可・フェデレーション機能を簡単に実装可能
        • 認証用のUIコンポーネントが提供されており、UIタグを配置するだけで、サインイン、サインアップ、パスワード復旧機能が実装されたコンポーネントを実装可能
      • Storage
        • Static content のシンプルな管理
      • Interactions
      • PubSub
        • リアルタイムなデータのやり取り
      • Notification
        • キャンペーンや分析機能を持ったプッシュ通知
      • Predictions
        • AI/ML コンテンツの組み込み
        • テキスト翻訳、文字読み上げ、Object Detection、文章のネガポジ判定といった機能が簡単に実装できる
        • 対応するAWSサービス
      • XR
        • AR/VR コンテンツの組み込み
  4. アプリケーションのデプロイ
    • デプロイ先
      • Amplify Console を用いたデプロイ
      • CloudFront and S3
        • コマンドラインからデプロイする
        • AWS CodePipeline などAmplify Console を用いないデプロイを実施する場合
        • CI/CDやソースリポジトリとの連携が不要なシンプルなデプロイはこっち

 

## 直近のアップデート

 

## よくあるケース

  • 複数の環境(prod, stagingなど)を利用したい
    • Amplify Console を利用した複数環境のデプロイ
    • Multiple Environment による環境構築と接続先の切り替え
    • Branch とバックエンドを紐づけることで、環境ごとのCI/CDパイプラインの構築が可能
  • Amplify CLI に対応していないバックエンドの構築
    • 任意のCloudFormation テンプレートをカスタムカテゴリとして定義できる

 

## 雑感

AWSWebフロントエンド 、モバイルアプリの開発を加速させるプラットフォーム。連携部分や、モバイル特有の部分をAmplify が行ってくれることで、価値のある部分に集中することができる。

複数環境の構築やそれを利用したテストまではカバーされている。対応していない部分はCloudFormation を記述することでカスタムカテゴリとして利用できるようになるみたいだが、用法用量は守ったほうが良さそう。

Amazon Pinpoint

# Amazon Pinpoint

https://d1.awsstatic.com/webinars/jp/pdf/services/20171109_AWS-BlackBelt-pinpoint.pdf

## グロースハックとは

  • 概要
    • データからKGIKPIを定め、施策を打ち、振り返りを繰り返す
    • 顧客価値の最大化(プロダクトの改善)と事業の成長にフォーカスする
  • 代表的なフレームワーク AARRR!
    • Acquisition : 獲得
      • 新規ユーザーがどこから流入するか
    • Activation : 活性化
      • その中で何%がハッピーな体験をしたか
    • Retention : 継続
      • 彼らはまたサービスに戻ってきてくれるか
    • Referral : 紹介
      • 彼らはサービスを友達に紹介してくれるか
    • Revenue : 収益
      • このサービスで収入は得られるか
  • AARRR!の課題
    • ユーザー体験の価値最大化という視点がないので、部分最適に陥ってしまいがち
  • ユーザー価値を最大化するために
    • 適切なエンゲージメントとそこに至る課題
      • タイミング
        • どうやって適切なタイミングを知るか
      • ターゲット
        • 対象をどう抽出するのか
      • 内容
        • メッセージをどう最適かするのか
      • 結果
        • どうだったか
  • これらの課題にAmazon Pinpoint で立ち向かう

 

## Amazon Pinpoint とは

  • できること
    • ユーザ行動の解析とかしか
    • ターゲッティング通知配信
      • プッシュ、EmailSMS
      • 以前はDBWorker + SNS でデータを抽出してターゲッティングが必要だった
    • 配信数、開封率等の把握
  • 主な機能
    • キャンペーン
      • 条件指定した(動的)セグメントとインポートした(静的)セグメント
        • S3からファイルをインポート
        • 利用状況や標準属性から絞り込み
      • 配信チャネル
        • モバイルプッシュ
        • Email
        • SMS
        • 配信チャネル別の分析
      • スケジューリング
        • 即時配信
        • 予約配信
        • 繰り返し配信
      • A/Bテスティング
        • メッセージのA/Bテスト
          • 最大5つのメッセージを作成し、どれだけの割合で送るかを決められる。それを分析できる
        • スケジュールのA/Bテスト
    • 利用状況・イベントのトラッキングとストリーム
      • SDKを利用することで容易に
      • イベントベースのファネル分析も可能(LP閲覧まで行った、住所入力まで行った、内容確認まで行った、購入ボタンをクリックするところまで行った)
      • イベント情報をKinesis Streams, S3
        • データの再利用性を高める
        • 分析基盤の拡張性を高める
    • ダイレクトメッセージ
      • チャネルではなく、個別プッシュも可能
      • Amazon SNS Mobile Push との使い分け
        • 基本的にはAmazon Pinpoint を利用する
        • バイストークンの管理の煩雑さがない
        • 分析ダッシュボードも標準で付いてくる
        • 多くの場合、SNSで行われていた一斉配信はPinpoint でのセグメンテーションプッシュに置き換え可能
    • プロジェクトのオプション
      • 送信速度の調整などができる
        • 1日にユーザが受け取るメッセージの最大数
        • キャンペーン当たりの最大メッセージ数
        • 配信除外時間
        • 単位の変換

 

## Amazon Pinopint の運用パターン

  • 属性ベースのセグメントパターン
    • 条件によってメッセージを送信する対象を決める
  • セグメントインポートパターン
    • Athena RDSに入っている個人データからターゲットを抽出しS3に保存。そのファイルをAmazon Pinpoint にインポートして利用
    • 静的なデータ
  • 速報パターン vs 非速報パターン
    • 速報パターンだと、ユーザーが一斉にサイトに訪れる可能性があるのでページのサーバが大量の一斉アクセスに耐えられるようになっていないといけない
    • 非速報パターンではユーザーは徐々に訪れるのでAutoScaling でも耐えられる

 

## さらに高度な分析

 

## 雑感

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 の特徴

  • 特徴
    • サーバーレス
    • 他のAWSサービスとの連携
    • セキュア
    • グローバル
    • 機械学習インサイト
    • カスタマイズと埋め込み
    • ブラウザの身で全機能が利用可能
  • 用語
    • フィールドリスト
      • RDBでいう列の一覧
    • ディメンジョン
      • グルーピングの軸
    • ビジュアル
      • グラフ
    • 分析
      • 複数のビジュアルを組み合わせて作成
    • SPICE
      • 高速なインメモリからムナデータベース
      • QuickSight に内蔵
      • S3PC上のファイルや、RDBの一部をSPICEに取り込んで高速分析
      • RDB上のデータは直接SQLを発行してアクセスも可能
  • QucickSight のユーザー

 

## ML インサイト

  • 機械学習ベースのインサイト
    • MLベースの異常検知
    • MLベースの予測
    • 自動ナラティブ
      • わかりやすい文章で分析結果を提供
  • Amazon QuickSight SageMaker との連携
    • ビルトインモデルに代えて、独自のモデルを利用可能に
    • SageMaker で作成した独自モデルと連携
    • ポイント&クリックで連携
    • 可視化とインサイトを高速化

 

## 埋め込み

  • Web サイトへのダッシュボード埋め込み
    • フル機能のダッシュボードをiFrame で埋め込み
    • 閲覧にはQuickSight のアカウントが必要のため、パブリックなWeb サイト向けではない

 

## カスタマイズ

  • テーマ
    • UIのカスタマイズが可能
    • グラフのカスタマイズも可能
    • 条件付き書式
    • ワンクリックフィルタ
    • モバイルアプリ用の機能

 

## データ操作の改善

  • クロスソースジョイン
    • 複数のデータソースにまたがったジョインを実現
    • 結果セットがSPICEに格納されるため、複数データソースを利用する際はデータ量に注意が必要
  • アクセスコントロール
    • IAM ポリシーや QuickSight ユーザ/グループに紐づけられる
    • S3, Athena, RDS, Redshift に対応
  • Amazon Athena Workgroup サポート
    • Athena データセット作成時に、利用するWorkgroup を指定可能に
    • 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サービス
    • 特徴
      • サーバーレス
      • VPC内からアクセス
      • セキュア
      • 柔軟な軌道方法
      • データソースのメタデータ管理
      • 他のAWS サービスとの連携
      • Notebook での開発
    • 構成要素
      • データカタログ
      • クローラー
        • Glue のデータカタログにメタデータを作成するプログラム
        • 分類子の優先度に従って、スキーマ情報を自動で判断する
      • スキーマ管理
        • データカタログに登録したテーブルのスキーマのバージョン管理することが可能
      • 接続管理
        • データをクロールする際のアクセス方法
      • サーバレスエンジン
        • ジョブ
        • Worker Type
          • Glue 内のSpark ジョブに割り当てるワーカーのタイプを変更可能に
          • DPU という単位(4vCPU, 16GB)
        • DynamocFrame
          • SparkSQL DataFrame と似たGlue特有の抽象化の概念
            • ETLに特化している
            • DynamicFrame はデータ全体を表し、DynamicRecord はデータ一行を表す
            • DataFrame DynamicFrame 間でそれぞれ変換することができる
        • Choice
        • ブックマーク機能
          • ジョブの実行状態を保持する機能
      • サーバーレスETL処理の使い分け
        • 小規模
        • 中規模
          • AWS Glue Python Shell
          • Lambda に比べてメモリ量が多い
          • Redshift EMRAthenaに対するSQLベースの分析
        • 大規模
          • AWS Glue Spark
      • 独自ライブラリの利用
      • スケジューリング
      • ワークフロー作成機能

 

## 開発

  • ETLジョブのコードを開発・実行する環境
  • SageMaker Notebook

 

## ネットワーク・セキュリティ・監視

  • Glue からVPC Endpoint 経由で他のサービスにアクセス
  • Glue からVPC Endpoint 経由でVPC Peering を通して他のVPCリソースへアクセス
  • セキュリティグループ
  • Glue 内のアクセス許可
    • Glue 内で管理するアクセスポリシー
    • データカタログリソースへのアクセス制御
    • データカタログに対するクロスアカウント・クロスリージョンのアクセス制御
  • 暗号化
    • データカタログ、接続パスワードのKMSを利用した暗号化
  • モニタリング
    • クローラー・ジョブステータス・ジョブの実行状況が確認可能
      • CloudWatch との連携
      • ジョブ失敗時にSNS通知やLambdaを起動する
      • Spark のメモリ監視
    • Continuous Logging
      • Spark ETL ジョブの進捗状況をリアルタイムに追跡できる機能

 

## ユースケース

  • データカタログを用いたメタデータ管理
    • EMR/Athena/Redshift Spectrum を利用する際のメタデータ管理に利用
  • ジョブによるSQLの定期実行
    • トリガー・Python Shell を用いてRedshift に定期クエリを実行し、データの加工を行う
  • WorkFlow 機能を用いたETLパイプライン
    • WorkFlow 機能を用いて単一ジョブではなく、複数ジョブを組み合わせて実行する
  • サーバーレスアナリティクス
    • Glueのデータカタログを利用する
    • SparkSQL を用いて標準SQLSageMaker Notebook を用いて分析を行う
  • データレイクを用いたログ分析基盤
    • スピードレイヤ・バッチレイヤを活用したログ分析基盤
    • アーキテクチャ
      • fluentd -> Kinesis Data Stream
        • スピードレイヤ
          • Kinesis Data Firehose -> Elasticsearch Service
        • パッチレイヤ
          • Kinesis Data Firehose -> S3 <-> Glue
          • S3 のデータを分析サービスを用いて分析
  • Glue SageMaker を用いた機械学習基盤
    • Glue WorkFlow を利用したETL機械学習のワークフロー

 

## まとめ

  • Glue はサーバレスのETLサービス
  • クローラー・データカタログでメタデータを管理
  • EMR/Athena/RedshiftSageMakerなどの他のサービスとセキュアに連携

 

## 雑感

機械学習や分析をする際にデータレイクのデータはそのままでは利用できない。それを可能にするためにデータカタログを作成する必要がある。Glue ETL処理を行い、他のAWSサービスが分析をできるようにするサービス。

ただ、これだと部分的にしかできずに他のサービスのセットアップも必要になる。そこでAWS LakeFormation がある。

課金はETL処理をするためのリソースと各種サービスの料金がかかる。

AWS Lake Formation

# AWS Lake Formation

https://d1.awsstatic.com/webinars/jp/pdf/services/20191001_BlackBelt_LakeFormation_A.pdf

## データレイクとは

  • データから価値を見出す業務が増え、データは年々増えていく
  • データにアクセスする人々も増えている
  • 分析対象のデータに対する要件も増えている

 

  • データレイクとは
    • 全ての構造化データと日構造化データを保存できる一元化されたリポジトリ
    • データをそのままの形で保存できるため、データを構造化しておく必要がない
    • ダッシュボードや可視化、ビッグデータ処理、リアルタイム分析、機械学習など様々なタイプの分析を実行できる
    • 分析の結果、意思決定を行える
  • なぜデータレイクが必要か
    • 構造化、反構造化、非構造化データの取り扱い
    • ペタバイト、エクサバイトに渡る拡張性
    • 様々な分析および、機械学習ツールとの連携
    • データの移動を伴わずにデータを処理
    • 低コストなデータの保存と分析

 

## AWS Lake Formation 登場の背景

  • データレイクを構築するには(数ヶ月単位の準備が必要)
    1. ストレージのセットアップ
    2. データの取り込み
    3. クレンジング、整形、データのカタログ化
    4. セキュリティの設定と適用
    5. 分析にデータを活用できるようにする

 

  • AWS Lake Formation の概要
    • データの取り込みと構造化(ブループリント)
      • データ管理のテンプレートを提供
      • Glue のトリガー、ワークフロー(一連のETL処理を行う)、クローラー、ジョブを自動で作成
      • 自動的にデータ取り込み
        • データベースからのバルクロード
        • ログをインクリメンタルロード
      • 整形、暗号化
      • S3バケットに保存&アクセス(IAM
        • アクセスを行う対象のS3パス(Data Lake Location
        • Data Lake Location に登録したパスに対するアクセス許可(Data Location
          • データベースやテーブルの作成ができるようになる
        • 以前は様々なサービスに対して設定を行わなければならず、辛かった
    • セキュリティ&コントロールパーミッション
      • ユーザーはAWSサービス(Amazon Athena, AWS Glue, Amazon Redshift, Amazon EMR)を通してアクセス。管理者はLake Formation 上でユーザーのアクセス制御を設定
      • SQLライクなGrant / Revoke でシンプルなアクセス制御を実現
      • 適切なユーザ、グループに正しいデータへのアクセス制御を定義
      • データベース、表、列の単位の粒度で制御可能
      • パーミッションの種類
        • データロケーションのアクセス許可
          • 登録されたS3にデータベースまたはテーブルを作成するため
        • データカタログのアクセス許可
          • データカタログには、基となるデータに関するメタデータが格納される
          • メタデータはテーブルとその集合であるデータベースとして編成されている
          • データカタログのアクセス許可は、データベースとテーブルを作成、編集、削除する権限を Grant / Revoke で与える
        • データアクセス許可
          • ユーザーに対してテーブル、列単位の権限付与
        • 暗黙的なアクセス許可
          • 何かを作成した場合、暗黙的に作成したモノに対しての権限が与えられる
    • 協調&利用(データカタログ)
      • メタデータカタログを利用した検索と定義確認
        • Apache Hive(Athena) メタストアで行うのと同じ方法で、AWS メタデータを保存、解釈付け、共有できるマネージドサービス
      • 全てのアクセスはIAMポリシーによりチェック
      • 新しいデータが取り込まれたり、ツールが変更されてもポリシーにより保護可能
      • アクセス時の連携
        • ユーザーは各種AWS分析サービスに対してクエリを投げる
        • AWS サービスはLake Formation に対してS3バケットに対してのアクセス権限を要求
        • Lake Formation から取得したクレデンシャル(取得できる範囲を制限)を利用してS3のオブジェクトへリクエストを投げる
    • 監視&監査(ロギング)
      • アクセス要求や発生したポリシー例外を記録
      • アクティビティ履歴で変更ログやログデータの入手経路をレビュー
        • CloudTrail

 

  • Lake Formation AWS Glue の関係
    • Glue ETL(抽出・変換・ロード)を行うジョブとデータカタログを持つマネージドサービス
    • Lake Formation AWS Glue の拡張版とも言える
    • Lake Formation Glueとデータカタログを共有している
    • Lake Formation のジョブとクローラーGlue のジョブとクローラを呼び出している
    • セキュリティ強化やブループリントによるデータ取り込みなどでより便利にGlueの機能を使えるようになっている
  • AWS Glue からLake Formation への移行
    • AWS Glue ではアクセスの権限管理をIAMを介して行なっている
    • 対してLake Formation では自身で権限管理をしている
    • 移行の際にはアクセス許可モデルの移行が必要になる
    • IAMAllowedPrincipals という平行稼働時の運用をサポートするツール(移行後はOFFにすることを推奨)

 

## 雑感

後ろでAWS Glue を利用しているが、より一連の操作を行いやすくし、AWSでデータレイクを構築・運用するためのマネージドサービス。データのETL処理や権限管理をメインで行ってくれる。利用料金自体はかからず、分析サービスやデータストアの料金のみがかかる。シンプルになるのであればAWS Glue を利用すればいいが、そうではない場合はAWS Lake Formation を利用する感じだと思う。

一番のメリットは散らばりやすいIAMの管理がLake Formation にまとめられ、管理がしやすくなることだと思う(もしGlueをすでに利用している場合でも移行パスは提示されている)。また、ブループリントによりETL処理が楽になる部分があるかと思うが、(これ自体はGlueで提供されている機能かもしれないので)確認してみる。

テーブルレベルではなく、行単位で権限管理ができるのはすごいと思った。分析者に見てはいけないデータを見させないためのモノであるとは思うが、ちょっと権限管理が面倒になるかな、とも思った。

公式(モヒカン)漫画もあった。

aws.amazon.com

Amazon Managed Streaming for Kafka

# Amazon Managed Streaming for Kafka

https://d1.awsstatic.com/webinars/jp/pdf/services/20191120_AWS-BlackBelt_AmazonMSK.pdf

## Amazon Managed Streamingfor Apache Kafka(MSK)とは

  • フルマネージドで可用性が高く、セキュアなApache Kafka
  • 他のデータソースからデータを一時的にキューイングして他のサービスへ連携する
  • 分散データストリーミング・プラットフォーム

 

## Apache Kafka とは

  • 全体像
    • Kafka のクライアントとして、プロデューサーとコンシューマーが存在する
      • Pub: プロデューサー
        • トピックと値を指定してキューに値を送る
        • リーダーレプリカのみに書き込みを行う
      • Sub: コンシューマー
    • Kafka は複数のサーバーでクラスターを構成しており、スケーラビリティと可用性を確保している
    • コンポーネント
      • ブローカー
        • クラスターとして動作し、データの受配信を担う
      • トピック
        • メッセージを種別で管理する
      • パーティション
        • ブローカー上に分散配置され、トピックのメッセージが格納される
        • 冗長性確保のためにブローカー間でコピーされた複数のセプリカを構成する(リーダーレプリカと複数のフォロワーレプリカ)
        • リーダーレプリカに対して書き込みが行われる
        • フォロワーレプリカはリーダーレプリカに書き込まれた内容を複製する(リーダーは同期が取れているかを把握している)
        • コンシューマーのメッセージ読み込みもリーダーレプリカのみから行われる
      • オフセット
        • メッセージがパーティションに入れられた際に付与されるシーケンシャルな番号
        • パーティション単位で最初に取得したメッセージをZooKeeper もしくはKafkaが覚えていてくれる
        • どこまで読み出したかを管理することができる
      • ハイウォーターマーク
        • レプリカによる複製が完了済みのオフセット
        • コンシューマーはハイウォーターマークのデータのみ取得可能(=レプリカに複製済みのキューだけサブスクライバは取得できる)

 

## Amazon MSKの機能

  • Amazon MSK はコントロールプレーンの操作を提供
  • データプレーンの操作はApache Kafka APIをそのまま使用可能
    • トピックの作成や管理
    • プロデューサーからのデータの入力
    • コンシューマからのデータの取得
  • アーキテクチャ
    • Amazon MSK
      • Broker node
      • Zookeeper

 

Kafka on EC2 Amazon MSK を利用した場合の違い

  • Kafka on EC2
    • 自身で全てデプロイ
    • EBSまたはインスタンスストアにデータを保存
    • インスタンスタイプは任意のものを選べる
    • ネットワーキングは自身で設計
  • Amazon MKS
    • 複数AZに自動的にデプロイ
    • MSK管理下のEBS
    • M5
    • クラスタ内はマネージド。クライアントからはENI経由で接続
    • アップグレードはBlue/Green デプロイで行う。
      • シングルクラスタ構成
      • アクティブ・スタンバイ構成
    • パフォーマンスチューニングについてはKafka on EC2と違いはない
    • MSKによる監視
      • CloudWatch と連携
    • MSKのセキュリティ機能
      • 保存データ・通信データの暗号化
      • IAMによる権限管理
      • TLSクライアント認証
      • コンプライアンスの認証を取得
    • クラスタのバックアップ機能は未提供

 

## 運用

  • 構成管理
    • ブローカー・トピック・ZooKeeper のデフォルト構成を提供している
    • カスタム構成を作成することも可能
    • カスタム構成で既存のクラスタを更新することも可能
  • スケーリング
    • ストレージの拡張
    • ブローカー数の拡張
  • クラスタの耐障害性
    • 99.9%SLA
    • 障害が発生したノードはクラスタから切り離され、新しいブローカーに置換

 

Apache Kafka のベストプラクティス

https://aws.amazon.com/jp/blogs/news/best-practices-for-running-apache-kafka-on-aws/

 

Amazon MSKのベストプラクティス

  • クラスタを適切なサイズに設定する
  • ディスク容量を監視する
    • ディスクフルを防ぐ
  • Kafka の Data Retention パラメータを指定する
    • ディスクの空き容量を定期的に解放する
  • MSKの管理外にあるブローカーを追加しない
  • データ通信の暗号化を有効にする
  • パーティションの再割り当てを行う

 

## ユースケース

  • Amazon Kinesis との使い分け
    • Amazon MSK
      • Apache Kafka 互換
      • クラスタをプロビジョニング
      • シームレスなスケーリングが困難
      • オンプレミスからの移行が容易
        • Kafka MirrorMaker を利用してオンプレのKafka のデータをMSKにミラーできる
        • Kafka Connect を利用してKafka 周辺のシステムを接続できる
        • Schema Registry
    • Amazon Kinesis Data Streams
      • フルマネージドなサービス
      • 他のAWSサービスとの連携
      • スループットをプロビジョニング
      • シームレスなスケーリングが可能
  • Apache Kafkaユースケース
    • メッセージング
    • ウェブサイトのアクティビティ追跡
    • メトリクス
      • 分散したアプリケーションから運用監視データを集約して集計や統計処理を実施
    • ログの集約
      • ログのイベントデータをメッセージのストリームとして利用
    • ストリーム処理
    • イベントソーシング
    • コミットログ
  • Amazon MSK ユースケース
    • オンプレミスにある既存のApache Kafka クラスタの移行
    • 既存の自前で管理しているApache Kafka クラスタの移行
    • Apache Kafka の周辺ツールを利用している場合
    • それ以外の場合は基本的に Kinesis Data Streams が良い

 

## 雑感

基本的にはKinesis Data Streams を使うのが良さそう。ただ、既存のApache Kafka クラスタがあり、それを移行したい場合などにはAmazon MSK という選択肢が出てくる。

MSK自体はマネージドではあるが裏側にM5系のインスタンスがあるのでスケールやキャパシティやスケーリングに制限があるので最終的にはKinesis Data Streams に置き換えることを目指すのが良さそう。