#学習
15
アプリが複数AZかつAutoscaling設定されたEC2上で稼働している。データはDynamoDBに保管。アプリは各オペレーションが何回呼び出されたかをテーブルに記録し、呼び出される項目としてオペレーションIDと回数が含まれている。ログはcloudwatchlogsに格納される。ELBアクセスログに記録されたGETリクエスト件数がDynamoDBテーブルでのGET回数よりはるかに多いことが分かった。
原因は何か
- Get呼び出しが現行数を取得したら整合性のある読み込みを行う
- RCU
- WCU
- UPdateitem呼び出しが増加後の呼び出し状況を保存したら条件付き書き込みを使う
- 正解。上書きされることでカウントがずれるのではないだろうか
DynamoDB 条件式
PutItem オペレーションはキーが同じ項目を上書きします (存在する場合)。これを回避するには、条件式を使用します。これにより、問題の項目が同じキーを持っていない場合にのみ書き込みが続行されます。
Amazon DynamoDB のコアコンポーネント
-
テーブル
- 他のデータベースシステムと同様、DynamoDB はデータをテーブルに保存します。テーブルは、データのコレクションです。
- 項目
- 各テーブルにはゼロ以上の項目が含まれています。項目は、他のすべての項目間で一意に識別可能な属性のグループです。
- 属性
- 各項目は 1 つ以上の属性で構成されます。属性は、基盤となるデータ要素であり、それ以上分割する必要がないものです
-
プライマリキー
- パーティションキー
- パーティションキーという 1 つの属性で構成されたシンプルなプライマリキー。
- パーティションキーのみを含むテーブルでは、2 つの項目が同じパーティションキー値を持つことはできません。
- 複合プライマリキー
- 複合プライマリキーと呼ばれるこのキーのタイプは、2 つの属性で構成されます。
- 最初の属性はパーティションキーであり、2 番目の属性はソートキーです。
- パーティションキー
-
セカンダリインデックス
- インデックスは基本テーブルから作られる。
- DynamoDB はインデックスを自動的に維持します。基本テーブルの項目を追加、更新、または削除すると、DynamoDB はそのテーブルに属するすべてのインデックスの対応する項目を追加、更新、または削除します。
- インデックスを作成するときは、基本テーブルからインデックスにコピーまたは射影される属性を指定します。少なくとも、DynamoDB は基本テーブルからインデックスにキー属性を射影します。
- DynamoDB の各テーブルは、20 グローバルセカンダリーインデックス (デフォルトの制限) と、テーブルあたり 5 ローカルセカンダリーインデックスに制限されています
- テーブルで 1 つ以上のセカンダリインデックスを作成できます。
- セカンダリインデックス では、プライマリキーに対するクエリに加えて、代替キーを使用して、テーブル内のデータのクエリを実行します
- Global secondary index
- テーブルと異なるパーティションキーとソートキーを持つインデックス
- 最初からある項目では対応できない属性の抽出を行うための項目
- テーブルと異なるパーティションキーとソートキーを持つインデックス
- ローカルセカンダリインデックス
- テーブルと同じパーティションキーと、異なるソートキーを持つインデックス。
- 違う属性でソート検索したい時用
- テーブルと同じパーティションキーと、異なるソートキーを持つインデックス。
- Global secondary index
-
DynamoDB ストリーム
- DynamoDB ストリーム は、DynamoDB テーブルのデータ変更イベントをキャプチャするオプションの機能です。これらのイベントに関するデータは、ほとんどリアルタイムに、イベントの発生順にストリームに表示されます。
- 新しい項目がテーブルに追加された場合
- ストリームは、すべての属性を含む項目全体のイメージをキャプチャします。
- 項目が更新された場合
- ストリームは、項目で変更された属性について、「前」と「後」のイメージをキャプチャします。
- テーブルから項目が削除された場合
- ストリームは、項目が削除される前に項目全体のイメージをキャプチャします。
16
ALBEC2Autoscalingでeコマースアプリが動いている。注文サービスも同じ構成。注文サービスへリクエストが届いていないので原因を解決したい。
- WebアプリのELBの前段にAPIgatewayを作成。スロットルリクエストがwebアプリケーションにいくようにapiを構成する。サービスの呼び出しをキャッシュするように各注文サービスのelasticCashをセットアップする。注文サービスを呼び出す前にキャッシュをチェックするようにアプリケーションを変更する。
- メッセージのやり取りにキャッシュサービスを使うことはない
- autoscalingの容量改善。NLBへ切り替え。
- 問題解決に至らない
- 各注文サービスにSQSを作成。注文サービスをLambdaに置き換え。
- 正解。
Elasticcash
AWS ELB(ALB,CLB,NLB)を1分で掴む
17
オンプレのMYSQLを移行するときやり方は?
- RDS MYSQLとDMSレプリケーションインスタンスを作成する。DMSタスクを構成してフルロード戦略でデータコピー
- mysqldumpでローカルにデータを落とす。s3にコピーしてRDS Mysqlインスタンスにコピー
- Storagegatewayでs3にデータコピー。s3からRDSへ
- RDS MYSQLとDMSレプリケーションインスタンスを作成する。DMSタスクを構成してフルロードと変更データキャプチャ戦略でデータコピー
- 正解
DMSを使ったデータベース移行を試してみた
- レプリケーション方法
- 全ロード
- ソースデータベースからターゲットデータベースへ指定したテーブルデータがそのまま移行されます。
- 全ロード + CDC
- ソースで変更をキャプチャしながら、全ロードが実行されます。
全ロードが完了すると、キャプチャされた変更がターゲットにレプリケーションされます。
最終的に、変更のレプリケーションは安定した状態に到達します
- ソースで変更をキャプチャしながら、全ロードが実行されます。
- CDC のみ
- ネイティブのエクポート/インポートツールで一括ロードした後に、DMSは差分のみをレプリケーションします。
- 全ロード
18
AWSオーガニゼーションで管理下にあるAWSアカウントに予算を設定してアラーム通知を行いたい。
- 各開発アカウントで予算を作成。超過したらトピックにパブリッシュしてLambdaを連携設定。LambdaはIAMグループのポリシーを書き換える。
カスタマー管理ポリシーの編集 (AWS API)
余裕でいけますね。現実的にこんな運用あるのだろうか...