AWS Startup ゼミ2019 春期講習 補講＆おかわり編に参加した

概要

AWS LoftでAWS Startup Day 2019の春期講習補講＆おかわり編があったので参加してきた。
その時のメモ。

最初に

• 下記を週刊で公開していく予定
  【週刊 Ask An Expert #01】AWS Loft Tokyo で受けた質問まとめ 20190408-0412 #AWSLoft | AWS Startup ブログ

データストアどれを使えばいいのかわからない(@zabbioさん)

• よくある課題
  • サービスが多くてどれ選択すればよいのかわからない
  • RDBMSに入れっぱなし
  • RDBMSだけだとツライ
• 辛くなるケース
  • 当初と仕様が変わってきてRDBMSでやり続けるのがツライ
• マネージドサービスを使っていってほしい
  • 複雑な設定作業や手作業、運用コストを減らすために
• データストアの特定(RDS,Neptune,DynamoDB,Redshift…)
• 例:RDS->DMS->Kinesis->Firehose->Lambda
• データのマスキングしながらデータの移行とかも出来る
• 十分な停止時間が取れてデータベースエンジンが同一であればダンプツールを使う(mysqldump)
• 十分な停止時間が取れない場合は、DB純正のレプリケーションを組む
• 十分な停止時間が取れず、エンジンも異なる場合はDMS(AWS Database Migration Service（簡単、安全なデータベース移行）｜AWS)を使う
• ちゃんと検証をしよう
• 負荷エミュレーションを使う(mysqlslapなど)
• パフォーマンスインサイト(cloudwatch)
• Cloudwatch Logsでslow query logsの特定の文字列をフィルターしてLambdaでSlack通知とかも出来る
• パフォーマンスインサイトはAuroraMySQLではt2,t3は現状未対応

認証基盤ちゃんとしたい

• よくある課題
  • 認証基盤を統一したい
  • いろんな認証をしたい
• Amazon Cognitoを使おう
• 複雑な要件があったらLambda
• Amazon Cognito
  • 認証処理の実装を軽減
  • 認証情報の管理は不要
  • SNS,AD,ldPとの連携
  • サインイン、サインアップフォームを連携
• 複雑な要件ではAWS Lambdaでカスタムする
  • SESで数字を送って、その後にreCAPTCHAを使う
• ユーザー移行Lambdaトリガーを使って移行であれば、サービス停止無い
• CSVインポートだと、全ユーザーによるパスワード再設定が必要
• NIST 800-63-3(DRAFT NIST Special Publication 800-63-3) の資料がとても参考になる

ログをちゃんと扱いたい

• Data Lakeとは AWSの定義-> 多種多様なデータを一元的に保存、データを失わない、サイズ制限なああい、APIですぐにアクセスできる
• AWS の Data Lake = S3
• S3をData Lakeのコアにすることで、様々なサービスと連携ができる
• とりあえず生ログはS3に貯めておく
• CloudWatchのログをkinesis経由でS3に保存する
• EC2はCloudWatchLogs AgentでCloudWatchに送ることが出来る
• モニタリングが不要で分析がメインのログは Kinesis AgentでS3に送ることができる
• フロントエンドのログはKinesis Firehorseに送ることが出来る
• VPCのフローログは直接S3へ保存できる
• RDBMSにログを保存していた場合は、DMSを使ってS3に定期出力が可能
• 迷ったらKinesis Data Firehoseを使うことを考える
• 時系列データみたいなのは、10MBとか60sなどの単位でKinesisで指定して、S3へ保存できる
• 個人情報が含まれているなどマスクしたい場合、FirehoseからLambdaを呼んでマスクできる
• FirehoseからS3以外に、RedshiftやElasticsearchに移行しやすい
• 日本以外のリージョンだとKinesis Data Analyticsを使える
• AWS Glue : フルマネージドのデータカタログ + ETLサービス (Apache Spark)
• Amazon Athena : サーバーレスなインタラクティブクエリサービス
• Amazon EMR : Hadoopクラスターサービス, 最近ではSparkを使うことが多い
• ELBのログはそのままS3へ保存でき、ある程度構造化されている
• ELBのCSVログをGlueでparquet形式へ変更して、Athenaで検索できるようになる
• 構造化されていないFirehoseからのデータをGlueを非構造化データの正規化ができるので、きれいに処理したものをS3へ保存することができる
• 複数ソースから成るデータをEMRでデータ生成できる
• RAWデータをS3にしっかり貯める
• RDSのデータをGlueで定期的に抽出して、個人情報をマスキングしてS3へ保存できる。結果的に個人情報をきにせずに分析が出来るようになる
• BI,Dashboard: QuitckSight, Redash, Apache Zeppelin
• 機械学習系のサービスも最近充実

このあとにもセッションがあったが、上記内容である程度満足したのでここで退散した。

参加してみて

私個人的にはAWSアーキテクチャの基本の一つを知ることができたので参加して良かったと思う。
特にログの連携あたりは、一から自分で作る機会も少なく、技術範囲も広いので導入できるところからやっていきたいと思う。
あとはBIツールなんかはGoogleにしてもAWSにしてもわかりにくい範囲なので、触れられる機会があれば触れてみようと思う。
アーキテクチャ周りの知識幅が狭すぎるので、これからもっと色々参加して知識を増やしていきたい。