omuronの備忘録

個人的な備忘録

DynamoDB の基礎の備忘録

Lambda とセットで、DynamoDB をよく使うようになったですが、インデックス周りがいつもあやふやになるので、備忘録の作成。
DVA は取ってないから、この辺りは苦手です。
取るならちゃんと覚えておかないと。

DynamoDB

NoSQL

KeyValue もしくは KeyObject 形式の NoSQL に分類される DB 。
スキーマーレス なので、作成時にはプライマリーキーだけ指定すれば問題なし。
データ追加時に、属性( Attribute )は増やせる。
属性とは、RDS でいうカラムに相当するもの。

プライマリキー

作成時にプライマリキーの指定が必要。
プライマリキーには、以下の2種類がある。

  • パーティションキー
    • 必ず設定する
    • 後述のソートキーを指定せず、単独利用の場合は主キーになるので重複不可
  • ソートキー

セカンダリインデックス

プライマリキー以外で、絞り込みを実行したい場合に利用する。
セカンダリインデックスには、以下の2種類がある。

  • ローカルセカンダリインデックス (LSI)
  • グローバルセカンダリインデックス (GSI)
    • パーティションキーとソートキーを任意の属性に設定するイメージ
      • ただし属性値はテーブル内で一意である必要はない
    • 内部的には新しいテーブルができるようなもの
      • 遅くなる、課金が増えるなど注意が必要

まとめ

インデックスを多用する作りになる場合は、そもそも DynamoDB の要件にあってない可能性があるので注意したい。
RDS でいうレコードに相当するアイテム( Item )単位で、属性( Attribute )を変更できるのも特徴。
この辺りのテクニックは、re:Invent 2019 の「DynamoDBデータモデリング (CMY304) 」が参考になったので、クラスメソッドさんの レポート がとても役に立ちます。

「JAWS-UG 初心者支部 #31 監視編 サーバーのモニタリングの基本を学ぼう」受講 #jawsug_bgnr

jawsug-bgnr.connpass.com

CloudWatch って機能多くて把握しづらいですよね。
ハンズオンはありがたいです。

資料

www.slideshare.net

環境構築

CloudFormation テンプレートが準備されてます。
これでスタックを作ると、一発でハンズオン環境ができあがるし、後片付けも基本スタックを消すだけ。
CloudFormation を準備しているハンズオンに参加したのは初めてでした。
内容を読み解いて、理解しておきたいと思います。

CloudWatch メトリクス

資料のP41。
現地時間(リージョンの時間?)に変更ができました。
UTC でいつも見てる、かつ、複数リージョン使ってダッシュボード作ったりしてたので気にしてなかった...というか知らなかった。

f:id:omron:20200901212712p:plain

その他

ssm

AWS CLIプラグイン ssm を使うと簡単に ssh できるとのこと。

$ aws ssm start-session --target <インスタンスID>

セキュリティグループなどの設定をしなくても EC2 に入れるので、セキュアでいいですね。

CloudWatch Agent ウィザード

CloudWatch Agent をインストールしてるとウィザード形式でセットアップが可能。

$ sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard

セットアップで作成された json も資料にあるので参考に。

所感

CloudWatch ダッシュボードで大量にグラフ表示するのって気持ちよくないですか?
今回のハンズオンで、メトリクスとアラームの基礎が理解できるので、ダッシュボードにたくさんグラフ並べることができますね。
たくさんグラフ並べてうなってるだけで、仕事できる感をアピールできるのですが、テレワークだとこの方法は使えなさそうです。

自分で CloudWatch メトリクスを最初から設定することはなかったので、良い勉強になりました。
SNS トピックスを作成してメールで通知するのも簡単にできることを体験できたので活用していきたいと思います。

「JAWS-UG CLI専門支部 #166R CloudWatch基礎 (カスタムメトリック)」受講 #jawsug_cli

jawsug-cli.connpass.com

波田野さん AWS ヒーロー に選ばれましたね。
おめでとうございます。
いつも勉強になります。

AWS の勉強について

とにかく触る。
スーパーエンジニアな人はすぐ触るのを心がけてる。

  • AWSと付き合い始めてみる
    • とにかく触り始める
    • AWS 190 サービス
      • 早く触らないと増え続ける
  • 公式ドキュメントと付き合う
    • 全部で数十万ページ程度
  • ビジネスで使ってみる
    • 技術を目的にしない

全体把握 : 最後までやる、完了させる。
インプット :必ず復習する、やらない人との差はとてつもなく大きい
アウトプット :オリジナル手順でやってみる

ハンズオン

資料は connpass からリンクされている こちら

本手順は、Cloud9環境での実施を推奨します。

とのことですが、私は macOS(BSD, bash) 環境で触ってます。
今まで困ることはなかったのですが、今回は撃沈...

1.2. データファイルの作成 (handson-cli-cloudwatch.csv)

cat << EOF > ${FILE_DATA}
$(date -u --date='26 minutes ago' "+%Y-%m-%dT%H:%M:00Z"),10,0
$(date -u --date='21 minutes ago' "+%Y-%m-%dT%H:%M:00Z"),10,3
$(date -u --date='16 minutes ago' "+%Y-%m-%dT%H:%M:00Z"),10,6
$(date -u --date='11 minutes ago' "+%Y-%m-%dT%H:%M:00Z"),10,2
$(date -u --date='6 minutes ago' "+%Y-%m-%dT%H:%M:00Z"),10,9
$(date -u --date='1 minutes ago' "+%Y-%m-%dT%H:%M:00Z"),10,0
EOF

cat ${FILE_DATA}

BSD なら、日付操作のオプションが違うので、以下に変更して対応。

cat << EOF > ${FILE_DATA}
$(date -v+26M "+%Y-%m-%dT%H:%M:00Z"),10,0
$(date -v+21M "+%Y-%m-%dT%H:%M:00Z"),10,3
$(date -v+16M "+%Y-%m-%dT%H:%M:00Z"),10,6
$(date -v+11M "+%Y-%m-%dT%H:%M:00Z"),10,2
$(date -v+6M "+%Y-%m-%dT%H:%M:00Z"),10,9
$(date -v+1M "+%Y-%m-%dT%H:%M:00Z"),10,0
EOF

1.3. スクリプトの実行 (handson-cli-cloudwatch.sh)

$ sh ${FILE_CODE_SCRIPT};

An error occurred (InvalidParameterValue) when calling the PutMetricData operation: The parameter MetricData.member.1.Timestamp must specify a time within the past two weeks.

エラーが発生しました。
「Timestamp パラメータには、過去 2 週間以内の時間を指定する必要があります。」と指摘されてます。
Timezone がローカル環境は JST で作っていて、AWS 環境は UTC で動いているから問題が発生したと思われます。(まだ未検証)
GMT+9 進んでいる分、未来になってたことが敗因でしょうか。

所感

作業中に家庭的な割り込みがあったり、エラーの対応をしているうちに追いつけなくなってしまい、結果眺めるだけになってしまいました。
「最後までやる、完了させる。」がとにかく大事とのことですので、時間をとって最後までやらないと!というのは気持ち的には思ってますが「怠惰」な自分が頑張れるだろうか...

「JAWS-UG朝会 #12」 #jawsug_asa 受講メモ

jawsug-asa.connpass.com

今日もラジオ体操からスタート。

セッション① CloudFormation StackSets × Organizations

speakerdeck.com

全体像把握のためざっくり分類

  • AWS 内のネットワークとサーバーのセキュリティ
    • オンプレの人は得意な部分
    • 責任共有モデルの「お客様」設定部分
  • AWS 操作の IAM
    • AWS セキュリティの中核
    • AWS 直接操作に関わる
  • セキュリティを維持するための AWS サービス
    • AWS 独自の部分
    • 利用しなくてもセキュアにできる
    • 利用すると楽にセキュアにできる

ガードレールという AWS の設計思想

  • 従来は関所
    • 1つ1つチェック、詰まることもある
  • ガードレール
    • スピード出しすぎても外に出ないように

セキュリティサービス

  • CloudTrail
  • Config
  • GuardDuty
  • SecurityHub
  • Trusted Advisor
  • Control Tower

セキュリティ設定指針

Organizations

SCP - root の制御もできる

CloudFormation Stack

他のアカウントからスタックを流し込むことができる。
Organizations x StackSets - Organizations と連携させて自動でスタックセットが便利。
数百もアカウント持つと手動で設定は無理がある。

セッション② S3とCognito作るサーバレスアンケートフォーム

speakerdeck.com

既存サービス

  • 無料 - Google Forms
  • 有料 - Survey Monkey

AWS なら

  • EC2 + LimeSurvey
    • メンテが必要で起動しっぱなしだと気になる

アンケートに必要なこと

  • アンケート表示
  • アンケートデータの投稿
    • ここが厄介
  • アンケートデータの保存
    • S3
  • アンケートデータ投稿の通知
    • S3 通知 + Lambda

S3 のアクセスモデルとアクセス制御

不特定向けは便利だけどリスクが高い。
S3 での情報流出事件につながる。

不特定多数のアクセスを抑制する機能郡

  • パブリックアクセスブロック
  • バケットポリシー
  • オブジェクト ACL

アンケートにおける S3 バケットの分離

Cognito

  • Cognito User Pool:認証
  • Cognito Identitiy Pool:認可
  • Cognito Sync:今は AppSync に変わってる

JavaScript + Cognito

コンテンツバケットJavaScript を経由して、 Cognito Identity プールを利用して非認証者に IAM ポリシーを付与して、 S3 への PUT 権限を付与する。
複数の S3 を利用しているので CORS になるので注意。
データバケットに CORS を許可する必要あり。
リファラをみるので、コンテンツバケットからのアクセスを CORS に設定して許可する。

LT① JAWS SONIC 2020 実行委員からのお願い

JWAS SONIC 2020 & MIDNIGHT JAWS 2020
09/12 16:00 - 09/13 20:00 の 24H ぶっ続けイベント。

https://jaws-ug.doorkeeper.jp/events/109373/

LT② JAWS-UG朝会と認定試験とボク

SAP とったお話。
モチベーションを保つためにオンライン勉強会活用。

  • 朝4時おきを習慣化して勉強時間確保
  • 当日の朝会で試験対策の勉強
  • アウトプットしないのは知的な便秘

LT③ CDK でコンテナやろうぜ!(仮)

AWS CDK なれた言語でインフラをプログラミングするツール。
Fargate のリスナールールがうまく動かない。
FargateService.loadBalancerTarget の利用が必要だった。
CFn をクラス定義で抽象化されている。
細かな調整をしようとすると、どう抽象化されているか理解する必要あった。

所感

業務で疲れた後の勉強会とは違って、元気な状態で受講できるのはいいですね。
その分業務に影響が出ないようにしないと...さぁ仕事しよう。

「はじめての CircleCI」 #CircleCIJP 受講メモ

「はじめての CircleCI」のオンラインセミナーを受講の備忘録です。
受講後、資料は公開されたけど受講者向けのみかな...

はじめての CircleCI

Why CI/CD

CI

全てのコミットを積み重ねてそれをトリガーにしてビルドとテストを繰り返すこと。
チームの生産性・効率・満足度をあげるため。

CD

継続的デリバリー:常にリリース可能な状態を維持すること。
継続的デプロイメント:リリース作業に人間の意思が介在しない。

まずは、デリバリーを目指す。

エンジニアリングの効率化に欠かせない5つの指標

  1. Commit to Deploy Time :コミットからデプロイまでの時間
  2. Build Time :ビルド時間
  3. Quere Time :ビルド開始までの時間
  4. How often Master is Red :Master ブランチが壊れている時間
  5. Engineering Overhead :ツールメンテの時間

こちらも参考に

speakerdeck.com

「CircleCI 実践入門」という本も発売予定。

機能や特徴

  • マネージドサービス
  • 共通の yml ファイルによるテストの共通化
    • VCS に保存して履歴を同時に管理
  • Dockerサポート、高速起動
    • キャッシュ設定
  • SSH デバッグ機能
    • 最大2時間 Docker を残せる
  • パラレルジョブ、マルチコンテナ
    • 複数コンテナ同時実行で並列テスト
  • パイプラインでジョブ連結
  • Orbs
    • 設定の共有と再配布

QA

GitHub Actions との違い

如何に早く回すか、大人数でも回せるかなどが違い。 スペックの種類の多さ、同時実行数の多さなどでスピードに違いがでる。

一方、導入のしやすさは GitHub Actions にある。

CodeBuild との違い

Azure, GCP などにも CI/CD ツールがある。 そのクラウドにデプロイするための機能が多い。

マルチクラウド、マルチプラットホームへのデプロイは CircleCI がいい。

テスト結果のデータを使って次の改善を行うことができるのは CircleCI の特徴の一つ。 SSH ビルドも大きな特徴。スムーズに最初から最後まで動かすのは難しいので、早くデバッグできるのも大きな特徴。

所感

とりあえず「AWS ガッツリ」かつ「すでに Code シリーズで CI/CD パイプラインを構築済み」であれば、CircleCI に乗り換えるメリットは今の所ないかな...

「Data Engineering Study #2 データ収集基盤とデータ整備のこれまでとこれから」 #DataEngineeringStudy 受講メモ

お盆休みでサボってたので久しぶりの勉強会視聴です。

forkwell.connpass.com ハッシュタグ :#DataEngineeringStudy

登録者千人超えてますね。すごい。

基調講演「事業に貢献するデータ基盤を作ろう・考え方編」

speakerdeck.com

データ基盤は意思決定に使えない/使われないと意味がない。
作ることが目的になってないか注意する。

データ整備は技術よりも段取りとコミュニケーションの比重が高い。
他と違う役割があるので担当者(データアーキテクト)を置くほうがいい。

基盤と整備と利用のバランスを考える。

おすすめ本

QA

初期フェーズのスタートアップの分析基盤を考える時どんな構成にしますか? (コストの制約が厳しい中、今後の拡張性も踏まえて構成を検討する必要があると思ってます。)

基盤よりミニマムで最低限なことをやるほうがいい。

初学者の勉強方法は?

最近の話なので無い。知ってる人から学ぶ。

データ整備後の保守運用について。きちんと整備された状態を維持するにはどうすればいいか。

整備後はなくて常に保守が必要。エラーのチェック体制を作っておくかが大事。

事例紹介1「データ収集の基本と 「JapanTaxi」アプリにおける実践例」

www.slideshare.net

事業システムから生まれたデータを分析システムにいれる。

ファイルフォーマット種類

  • CSV,TSV
  • JSON
  • AVRO : バイナリ
  • Parquent,OCR : 列方向で圧縮している

事業 DB に select * などして直接負荷をかけない。
リードレプリカを活用するなど。

事業システムは売上を上げてて偉い。
分析システムはそうじゃないので注意する。

QA

押し付けあいになりやすいデータ整備する泥臭いタスクを組織的に前向きになれるようにどう取り組んでいますか?

利用している人のチームに入って分析しながらデータを取るのが最適。
難しいなら上司と目標を決めて取り組む組織にしないと難しい。

データマネジメント/データガバナンスについて、インフラエンジニアとしてシステムとプロセスの点で留意している点

メタデータを書けて共有できる場所を準備する。
データに対するノウハウを貯める場所を作るのがインフラ側の仕事。
クエリログを日々貯めるのは重要。使われてないテーブルがわかる。

こういうデータ取りたいんだけど、結構めんどくさいケースなど聞いてみたいです。

事業部が遠いケース。知り合いがいない場合など。
事業が遠いほどめんどくさい。
技術的じゃない課題。調整力が重要。

縦も横も際限なく増えるデータに対して、スケーラビリティ・レスポンス性能をどう設計するか。

クラウド使う。オンプレ使わない。従量課金でスケールできるものでやる。

事例紹介2「メルカリにおける分析環境整備の取り組み」

speakerdeck.com

現状:なぜ改善に取り組むのか?

基盤: BigQuery + Locker
クエリ実行ユーザー 700人/月 (社員数1,800人)
テーブル数 100以上/月

ありたい姿:改善のサイクルを回し続ける

負のサイクルはさけたい。
改善のサイクルを回すことで現状維持が楽になりさらに改善させ、攻めの改善もできる。

取り組み:レガシーなデータセットを廃止する

古いもののメンテナンスコストは削減したい。
レガシーテーブルを削除したいが古いテーブルで計算している KPI を利用しているチームがある。
レガシーな pipeline へ依存した業務があるのが問題。
キャンセル処理の取り扱いが新旧で違っていた。
業務要件を元に KPI の定義を見直してレガシーなテーブルへの依存をなくす。

基盤と指標と業務はセットで考える!

QA

データ整備におけるスピードと品質の両立について、どう取り組まれていますか?

品質を重視する。
データは目に見えない依存関係が発生する。
システム上現れないけど沢山の人が依存したテーブルが発生するので、品質をあげて運用コストをあげないようにする。

データ分析基盤のリファクタリングについて、タイミングや進め方のコツ等あればお聞きしたいです。

リファクタリングというかリプレイスの話ですが、レガシーなシステムを廃止する過程でニーズが見えてくる。
取引に関してキャンセルを除かずにデータを見たいというニーズがレガシーテーブルを廃止するときにわかったりなど。

データ分析基盤づくりの際に、運用のしやすさ、変更のしやすさをユーザとエンジニア間で調整するのが大変です。皆さんどのように変更予想や調整をしているのでしょうか?

データを処理するときに不可逆的な変換はできるだけ後にする。
明細に近い状態でデータを加工しておく。

所感

エンジニアの自己満足でシステムを作るのではなく、使うユーザーとコミュニケーションをとって改善を続けることが大事なのは、データ収集基盤に限った話ではないですね。
どうしても作るのが目的になったり、目標を達成するために無理やり形にしたりとか、作る立場としてはありがちなので気をつけないと。
作ったけど使われないシステムは悲しいですしね。

AWS AppSync サービスクォータ(制限)確認

AWS AppSync のサービスクォータ(制限)の確認メモ。

AWS AppSync エンドポイントとクォータ - AWS General Reference

Service Quotas

注意したほうが良さそうなところを抜粋。

Resource 説明: デフォルト値:
スキーマ ドキュメント サイズ スキーマ ドキュメントの最大サイズ  1 MB
GraphQL API ごとのスロットルレート 1秒あたりのAPIあたりのGraphQLクエリの最大数 1,000。クォータの引き上げをリクエストできます。
GraphQLリクエスト実行タイムアウト クエリ、変異、サブスクリプションの最大GraphQLリクエスト実行時間 30 秒
評価済みレゾルバテンプレートサイズ 評価済みレゾルバテンプレートの最大サイズ 5 MB
リクエスマッピングテンプレートサイズ リクエスマッピングテンプレートの最大サイズ 64 KB
レスポンスマッピングテンプレートサイズ 応答マッピングテンプレートの最大サイズ 64 KB
単一のリクエストで実行されたリゾルバー 1つのリクエストで実行できるレゾルバの最大数 10,000*
サブスクリプション ペイロード サイズ 購読 (WebSockets) から受信したメッセージの最大サイズ 240 KB
サブスクリプション ペイロード サイズ 購読から受信したメッセージの最大サイズ (WebSocket 上の MQTT) 128 KB
キャッシュキーの数 キャッシュキーの最大数 10* クォータの引き上げをリクエストできます。

所感

Lambda と同じ感覚で注意すればよさそうな感じです。
RDS も接続可能ですが、RDS Proxy を挟めるわけではないので、スパイクにはやっぱり注意が必要そう。
基本、データソースには DynamoDB に対して使うのがよさそうかな。