はじめに
常日頃から業務でAWSを触っていて、基本的なことは理解できたのでそろそろもう一歩深いところの知識を学んでみるかということで、Professional系の資格取得を目指そうかなと考えていました。
ただ、Solution Architect Associate、Devops Associateは持っていたのですが、Developer Associateだけ持っていなかったので、とりあえずAssociateの資格を揃えておこうかなと思い立ったので、Developer Associateに挑戦しました。
普通に受けても面白くないので、英語の勉強も兼ねてUdemyの英語セッション「Ultimate AWS Certified Developer Associate 2019」を利用し、英語だとどうしてもわからないところはホワイトペーパーやBlackBeltを活用して調べるという勉強方法を取りました。
今となって感じた英語で勉強するメリットとしては、AWSの知識としては理解したと思い込んでいる知識であっても、英語の意味がわからないのか、腹落ちしない部分があってよくよく調べてみると、実はAWSの知識として知らないことがあるということがありました。
その分勉強時間はかかりますが、個人的に非常に良い勉強になったので、備忘も兼ねて自分が知らなかった知識をまとめました。
ちなみに資格自体は910点で無事に合格でした。
勉強になった知識5選
S３ Server Side Encryptionについて
機能としては読んで字のごとくですが、S3に格納するオブジェクトをS3上で暗号化する仕組みになります。
オプションの種類としては三種類あります。
どのオプションを使用するかについては、管理コストと暗号化の柔軟性を鑑みて選択する必要があります。
- SSE-S3
- SSE-KMS
- SSE-C
それぞれの特徴は次の表のようになるかと思います。
| SSEの種類 | 管理コスト | 管理の柔軟性 | ユースケース | 考慮事項 |
|---|---|---|---|---|
| SSE-S3 | 低 | 低 | オブジェクトの暗号化はしたいが鍵の管理はしたくない場合。 | 暗号化時の監査証跡が残らない。 |
| SSE-KMS | 中 | 中 | オブジェクトの暗号化をしたいが鍵は管理したくない。ただし、鍵のローテーションや無効化ができるようにしたい。 暗号化時の監査証跡を残したい。 |
KMSのAPIコールの制限を考慮する必要がある。 |
| SSE-C | 高 | 高 | ユーザーが暗号化鍵を用意する必要がある。 | 暗号化リクエストはHTTPS利用する。 |
Lambdaのレスポンス性能について
Lambdaの性能はメモリ割当を増やすことで向上を見込むことができますが、それ以外にも見直せる点があります。
例えば、以下はdynamodbのテーブルからレコードを取得する例となりますが、
import boto3
def lambda_handler(event, context):
dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('sample')
result = table.scan()
return dump(result)
↑のように書くよりも、、、
import boto3
dynamodb = boto3.resource('dynamodb')
def lambda_handler(event, context):
table = dynamodb.Table('sample')
result = table.scan()
return dump(result)
↑のように書いた方が実行速度が上がります。
違いはDynamoDBインスタンスの初期化をLambda関数のハンドラメソッド外に書いている点です。Lambdaのハンドラメソッド外で定義されたオブジェクトは、コールドスタート時のみ初期化されるという性質を持っており、コールドスタート時以外はすでに初期化されたオブジェクトを使いまわすことができるため、インスタンスの初期化などコストの高い処理に適用することで、レスポンスの向上を見込むことができます。
逆にいうと、間違っても現在時刻などの可変な変数をハンドラ外に書くことがないよう注意する必要があります。
DynamoDBのパーティションについて
DynamoDBはRead/Writeのそれぞれにキャパシティを割り当てることができ、柔軟にリソース管理を行うことができますが、メトリクスを確認する限りではキャパシティが十分に足りている場合であっても、キャパシティが不足していることを示す「ProvisionedThroughputExceededException」が発生することがあります。
これはDynamoDBの性質として、テーブルに割り当てたキャパシティを各パーティションで均等分割して活用するため、一つのパーティションに負荷が集中してしまうことにより発生します。
パーティションはパーティションキーの項目の値により分散されます。そのため、本事象が発生した場合はパーティションキーの設計が誤っている可能性を疑う必要があります。
分かりやすいアンチパターンの例としては以下になります。特定の日時をパーティションキーに設定してしまっているため、その日1日のレコードは同じパーティションに書き込まれることになります。
DynamoDBの消費キャパシティユニットの計算方法
もう一つDynamoDBから。
結果整合性の場合の計算方法は理解していたのですが、昨年発表された強力な整合性の場合の計算方法についてはキャッチアップできておりませんでした。それぞれ以下のような計算方法になります。
| 整合性 | Read/Write | １レコードの消費キャパシティユニット |
|---|---|---|
| 結果整合性 | Write | レコードサイズ(1KBの倍数となるように切上) / 1) / 2 |
| 結果整合性 | Read | レコードサイズ(4KBの倍数となるように切上) / 4) / 2 |
| 強力な整合性 | Read | レコードサイズ(4KBの倍数となるように切上) / 4 |
強力な整合性の場合は、結果整合性の場合と比較して消費キャパシティが2倍になります。
Readはレコードサイズから4を、Writeの場合は1を割ると覚えておくと良いでしょう。注意点としては、レコードサイズがWriteの場合は1KB、Readの場合は4KBで割り切れない場合は、それぞれの倍数で繰り上げられて計算される点です。
例えば、レコードサイズが15KB、秒間リクエスト数4、結果整合性のRead処理の秒間キャパシティユニットを求める場合、15KBが4KBの倍数とするために16KBで計算する必要があります。16 / 4 / 2 * 4で答えは8となります。
エクスポネンシャルバックオフ
AWS SDKで提供されている自動再試行ロジックになります。エクスポネンシャルバックオフは、再試行間の待機時間を累進的に長くして、連続的なエラー応答を受信するという考えに基づいています。初回リトライ時は1秒後、次回リトライ時は3秒後、その次は7秒、、、というように徐々にリトライをかける時間を遅延させていくというものです。
リクエスト数の増加等によって負荷の高騰が起因してエラーとなった場合、１リクエストに対する重みが平常時と変わってきます。例えば１秒などの短い固定間隔でリトライしてしまうと、システムからすると過負荷な状態でただでさえ処理が困難な状態なのに、そのうえさらに定常的な負荷がかかることになります。
また、一時的なエラーであれば即座にリトライすることでレスポンスを得ることができますが、ネットワーク障害など長期に及ぶエラーの場合、短い間隔でリトライしてもしばらくの間はレスポンスを得られないことが多く、効果的なリトライができているとは言えません。
これを回避するための仕組みがエクスポネンシャルバックオフです。
さいごに
資格取得のために勉強をするメリットとして、気分が乗らない時でもお金を無駄にしたくないから頑張る、という強力な動機付けになる点にあると考えています。幸い今の会社では合格すれば受験料が支給されるため、より合格へのモチベーションを高めることができています。
これでAssociateレベルのAWS資格が三つ揃ったので、次は心置きなくProfessional資格を目指そうと思います。