AWS SAA受験に向けたAWSサービスとBlackBeltの整理
はじめに
2023年1月にAWS SAAを受験するので、
それに向けてAWSの各サービスとBlackBelt資料の要点について整理します。
AWS BlackBeltとは、AWS公式のオンラインセミナーのことで資料や動画が公開されています。
サービス
AWSの技術カテゴリーごとにサービスを抜粋して整理します。
ネットワーク関連
- ネットワーキングとコンテンツ配信
- VPC (Virtual Private Cloud)
- Route 53
- ELB (Elastic Load Balancing)
- CloudFront
リソース関連
コンピューティング
- EC2
- Batch
コンテナ
- ECS (Elastic Container Service)
- Fargate
ストレージ
- S3 (Simple Storage Service)
- EBS (Elastic Block Store)
- EFS (Elastic File System)
アプリケーション関連
データベース
- RDS (Relational Database Service)
- DynamoDB
- ElasticChache
ウェブとモバイルのフロントエンド
アプリケーション統合
- SNS (Simple Notification Service)
- SQS (Simple Queue Service)
ビジネスアプリケーション
- SES (Simple Email Service)
サーバレス
- Lambda
分析
管理関連
ネットワーク関連
ネットワーキングとコンテンツ配信
VPC (Virtual Private Cloud)
- CIDRのレンジ表記: xxx.xxx.xxx.xxx/xx
- アベイラビリティゾーン: AZは1つ以上のデータセンターで構成される, 1リージョン内にAZが複数存在
- サブネット利用できないIPアドレス(/24の例): 0, 1, 2, 3, 255
- ネットワークACL vs セキュリティグループ:
- VPCとのプライベートネットワーク: VPN接続 or 専用線(Direct Connect)
- GuardDuty: 脅威検出
Route53
(その他)
- レコードの種類: A, CNAME, Aliasなど
- ルーティングポリシー: シンプル, 加重, レイテンシー, フェイルオーバー, 位置情報, 地理的近接性, 複数値回答
- ヘルスチェック
ELB (Elastic Load Balancing)
- ELBの種類:
- ヘルスチェック: 設定値(しきい値など)に基づいてヘルスチェックし、正常なターゲットへのみルーティングする
- ALBの特徴と機能: 高度なリクエストルーティング
- NLBの特徴と機能: 暖機なしに急激なスパイクにも対応可能、固定IPが可能
- Autoscaling, ECS, WAF, Lambdaとの連携
- NLBはセキュリティグループが設定できない
CloudFront
- 動的コンテンツと静的コンテンツの配信
- 地域(GEO)制限: BlackList, WhiteListで指定可
- オリジンサーバの保護: Origin Access Identity(OAI)でS3のBucket へのアクセスをCloudFrontからのみに制限できる
- WAF連携
- AWS Shield による DDoS 攻撃対策
- CloudFrontとLambda@Edgeとの組み合わせ
リソース関連
コンピューティング
EC2
- AMI
- Key Pair: OSに対する認証機能
- Security Group
- EC2のストレージ: インスタンスストア, EBS
- EC2の購入オプション: オンデマンド, リザーブド, スポットなど
Batch
コンテナ
ECS (Elastic Container Service)
Fargate
ストレージ
S3 (Simple Storage Service)
EBS (Elastic Block Store)
EFS (Elastic File System)
アプリケーション関連
データベース
RDS (Relational Database Service)
DynamoDB
ElasticChache
ウェブとモバイルのフロントエンド
API Gateway
アプリケーション統合
SNS (Simple Notification Service)
SQS (Simple Queue Service)
ビジネスアプリケーション
SES (Simple Email Service)
サーバレス
Lambda
分析
Kinesis
管理関連
マネジメントとガバナンス
CloudWatch
CloudFormation
セキュリティ、アイデンティティ、コンプライアンス
IAM
AWS_BlackBelt_IAM Part1 AWS_BlackBelt_IAM Part2
CloudTrail
AutoScaling
SQLチューニング
SQLを速くするぞ
https://mickindex.sakura.ne.jp/database/db_optimize.html
ポイント
- サブクエリを引数に取る場合、IN述語よりもEXISTS述語を使う
- BETWEENはおしゃれなアクセサリ
- EXISTS述語のサブクエリ内では、SELECT * を使う
- 極値関数でインデックスを利用する
- 行数を数えるときはCOUNT(*)よりもCOUNT(列名)を使う
- GROUP BY 句でインデックスを利用する
- ORDER BY 句でインデックスを利用する
- UNION、INTERSECT、EXCEPT には ALL を付ける
- 実はインデックスが使用されていないという罠。
- 行ポインタによるアクセスが最速
- ワイルドカードは使わない
- 列番号は使わない
- 表に別名をつける
- 暗黙の型変換を回避する
- IN述語の引数リストには、最もありそうなキーを左寄せする
- ビューを濫用してはいけません
人工知能まわりの2022年のトレンド
AI 激動の年！2022年の人工知能10大トレンドと必読論文
https://ja.stateofaiguides.com/20221231-ai-trends-2022/
トレンド
- Stable Diffusion
- 「入力されたテキスト」をもとに画像を生成する「訓練済のAIモデル（Diffusion Model）」を搭載した画像生成AI
- テキストと画像の類似度をとらえる CLIPと、潜在空間上で高解像度・高速な生成を実現する拡散モデルLDMを組み合わせたもの
- LAION-Aesthetics と呼ばれる「美しい」画像のみを集めたデータセットを用いて訓練されているという特徴がある
- Whisper
- ChatGPT
- OpenAIによって開発された、人間の発話をシミュレートしてユーザーと自然なやり取りをするチャットボットのモデル
- 人間によるフィードバックを用いた強化学習
参考:
ES2023について
【JavaScript】ES2023の新機能
https://qiita.com/rana_kualu/items/84f66fe970f7feccf367
新機能
- Array find from last
- findLastの対応
- Hashbang Grammar
- シェルスクリプト同様にJavaScriptでも先頭行の最初にある#!のみコメントとして取り扱われる
リリース自動化に向けたブランチ戦略
リリース自動化の嬉しみとその手法
https://blog.kengo-toda.jp/entry/2022/02/17/193427
ブランチ戦略
リリースブランチを常時リリース可能状態にする
- デフォルトブランチやリリースブランチが「常時リリース可能」であることを前提としている場合が多い
- もしブランチが常時リリース可能でなかったら、リリース作業前に「リリース可能かどうか」を人間が検証する必要性が出てしまう
- リリース可能性検証のプロセスを自動化して、マージ前ビルドないしリリースビルドで自動的に検証されるようにする
「マージしたらリリースされてしまう」ことを「完成するまでマージするべきではない」と受け止めないことも必要
- トピックブランチの寿命は短いほうが開発効率に良い影響がある。リリースできないとわかっている変更は公開することは避けつつ高頻度に変更をマージするためにFeature flugなどの工夫をする
ソースコードブランチを管理するためのパターン
Base Patterns
- Source Branching
- Mainline
- Healthy Branch -> 各コミットに対しテスト実行などで自動チェックし、ブランチに欠陥がないことを確認する
Integration Patterns
- Mainline Integration
- Feature Branching
- Integration Frequency
- Low-Frequency Integration
- High-Frequency Integration
- Comparing integration frequencies
- Continuous Integration
- Comparing Feature Branching and Continuous Integration
-> 統合の頻度が高いほど、統合の関与が少なくなり、統合への恐怖が少なくなる
- Feature Branching and Open Source
- Pre-Integration Review
- Integration Friction
- The Importance of Modularity
- Personal Thoughts on Integration Patterns
The path from mainline to production release
- Release Branch
- Maturity Branch
- Variation: Long Lived Release Branch
- Environment Branch
- Hotfix Branch
- Release Train
- Variation: Loading future trains
- Compared to regular releases off mainline
- Release-Ready Mainline
Other Branching Patterns
- Experimental Branch
- Future Branch
- Collaboration Branch
- Team Integration Branch
Looking at some branching policies
- Git-flow
- GitHub Flow
- Trunk-Based Development
- Final Thoughts and Recommendations
個人的な整理
リリース可能状態が担保されたメインラインへ頻繁にマージしていくのが良い。 そのために、リリース見込みが経っていないものについては、
- もし大きい機能で完成していない場合、フィーチャーフラグなどによって使えないようにするなど工夫する
- デグレードなどが気になる場合、自動テストなどでカバーしていく
- DBなどのデータの観点は変更容易性次第
- セキュリティの観点はフレームワークと開発内容による
- バージョニング管理とリリースノートはリリース方式次第
リリースするものについては、
- （リリース物の切り戻しなど、アジャイルライクな考え方に繋がっていく。）
Effective Javaの要点ピックアップ
Effective Java 第３版 「ほぼ全章」を「読みやすい日本語」で説明してみました
https://qiita.com/nyandora/items/3e5ec76ca3881bc17924
本にも載っているよ、と説明したい際に。
オブジェクト生成まわり
- コンストラクタよりstaticファクトリメソッドで
- コンストラクタパラメータが多いときはビルダーで
- シングルトンはenumかprivateのコンストラクタで
- staticなメソッドとフィールドだけのクラスはprivateのコンストラクタでインスタンス化できないように
- リソースは直接結びつけるよりも依存性注入で
- オブジェクト生成は最低限に
- 使われなくなったオブジェクト参照は取り除く
- ファイナライザとクリーナーは使わない
- try-finallyよりtry-with-resourcesを使う
オブジェクト共通メソッドまわり
- equalsをオーバーライドするときは一般的な要件に従う
- equalsをオーバーライドするときはhashCodeを常にオーバーライドする
- toStringを常にオーバーライドする
- cloneのオーバーライドは原則NG。もしする必要がある場合は注意する
- Comparableの実装を検討する
クラスやインターフェースまわり
- クラスとメンバーへのアクセス可能性は最小限に
- publicのクラスではpublicのフィールドではなくアクセッサーメソッドで
- 可変オブジェクトは最小限に
- 継承よりもコンポジションで
- 継承する場合は継承される前提の設計および文書化する、でなければ継承を禁止する
- 抽象クラスよりインタフェースで
- 将来を見越したインタフェースを設計する
- タグ付きクラスにせずクラス階層を分ける
- 非staticのメンバークラスよりもstaticのメンバークラスを
- ソースファイルを単一のトップレベルのクラスに限定する
ジェネリクスまわり
- 原型を使わない
- 無検査警告を取り除く
- 配列よりもリストを
- ジェネリック型を使う
- ジェネリックメソッドを使う
- APIの柔軟性向上のために境界ワイルドカードを使う
- ジェネリクスと可変長引数を注意して組み合わせる
- 型安全な異種コンテナを検討する
enumやアノテーションまわり
- int定数の代わりにenumで
- ordinalの代わりにインスタンスフィールドで
- ビットフィールドの代わりにEnumSetで
- ordinalをインデックスにする代わりにEnumMapで
- enumをインタフェースで拡張可能に
- 命名パターンよりアノテーションで
- 常にOverrideアノテーションを付けること
- 型を定義するためにマーカーインターフェースで
ラムダやストリームまわり
- 無名クラスよりラムダで
- ラムダよりメソッド参照で
- 標準の関数型インターフェースで
- ストリームを注意して使う
- ストリームは副作用のない関数で
- 戻り値の型はStreamよりCollectionで
- ストリームの並列化は注意する
メソッドまわり
- パラメータの正当性を検査する
- 必要な場合、防御的にコピーする
- メソッドのシグニチャを注意深く設計する
- オーバロードを注意して使う
- 可変長引数を注意して使う
- nullではなく、空コレクションか空配列を返す
- Optionalを注意して返す
- すべての公開API要素に対してドキュメントコメントを書く
全般
- ローカル変数のスコープは最小限に
- forループよりfor-eachループで
- ライブラリを知り、ライブラリを使う
- 正確な答えが必要である場合、floatとdoubleは避ける
- ボクシングされた基本データより基本データ型で
- 他の型が適切な場所では文字列型を避ける
- 文字列結合のパフォーマンスに用心する
- インターフェースでオブジェクトを参照する
- リフレクションよりインターフェースで
- ネイティブメソッドを注意して使う
- 注意して最適化する
- 一般的に受け入れられている命名規約を守る
例外まわり
- 例外的な状態だけ例外を使う
- 回復可能な状態にはチェック例外で、プログラミングエラーには実行時例外で
- チェック例外を不必要に使うのは避ける
- 標準的な例外を使う
- 抽象概念に適した例外をスローする
- 各メソッドがスローするすべての例外をドキュメント化する
- 詳細メッセージにエラー記録情報を含める
- エラーアトミック性に努める
- 例外を無視しない
スレッドまわり
- 共有された可変データへのアクセスを同期する
- 過剰な同期は避ける
- スレッドよりエグゼキュータ/タスク/ストリームで
- waitやnotifyより並行処理ユーティリティで
- スレッド安全性をドキュメント化する
- 遅延初期化を注意して使う
- スレッドスケジューラに依存しない
