by shigemk2

当面は技術的なことしか書かない

awscli 2.18.6

  • securitylake: リソースARNのリクエストバリデーション用正規表現を更新
  • codepipeline: CodePipeline V2で、失敗したステージの自動リトライと条件不成立時のスキップをサポート
  • transfer: SFTPコネクタを使用する顧客がファイル転送ステータスをクエリ可能に
  • mailmanager: アーカイブメッセージのメタデータ表示とエクスポートをサポート
  • supplychain: AWS Supply Chainのインスタンス管理APIを追加(作成、削除、取得、一覧、更新)

github.com

awscli 2.18.5

  • elbv2: zonal_shift.config.enabled属性を追加し、describe-target-health APIに管理上のオーバーライド情報を追加
  • robomaker: すべてのAPIアクションにサポート通知を追加したドキュメント更新
  • emr: インスタンスフリートクラスターに新しいパラメータ"Context"を追加
  • appflow: SalesforceのOAuth2GrantTypeに関するドキュメント更新
  • guardduty: ネットワーク接続情報の新しいフィールドを追加

github.com

awscli 2.18.4

  • neptune-graph: アカウント許可リストで16 m-NCUグラフをサポート
  • route53resolver: DNS-over-HTTPS (DoH)プロトコルを使用するルールで、SNIを含むターゲットアドレスをサポート
  • iotfleetwise: キャンペーン関連APIのバリデーションを改良
  • dms: データ移行操作APIとFailedDependencyFaultエラーメッセージを追加
  • elastic-inference: サービス終了通知のドキュメント更新
  • acm-pca: AWS Private CAのドキュメント更新
  • ec2: 共有のオンデマンドキャパシティ予約の課金割り当てをサポート
  • cryptography: cryptographyバージョンの上限を43.0.1に更新
  • socialmessaging: エンドユーザー向けWhatsAppメッセージ送信APIを公開
  • outposts: Outpostsの注文ステータスに"DELIVERED"を追加
  • ecs: Elastic Inferenceの提供終了を通知するドキュメント更新
  • timestream-influxdb: DbInstanceおよびDbParameterGroup名のバリデーションルールを更新

github.com

Kubernetes probe

Kubernetesのプローブは、Kubernetes環境内のコンテナで実行されているアプリケーションの健康を監視するための重要なメカニズムです。これらはコンテナの運用状態を確認し、サービスの信頼性と可用性を確保するために適切に行動することを目的としています。Kubernetesには主に3種類のプローブがあります。

  1. Liveness Probes(生存プローブ):

    • 生存プローブは、コンテナが実行中であるか、または復旧不可能な障害状態(デッドロックなど)にあるかを判断するために使用されます。生存プローブが失敗すると、Kubernetesはコンテナを再起動してサービスの機能を復元します
    • 一般的な方法として、生存プローブ用には低コストのHTTPエンドポイントを使用し、準備完了プローブよりも高いfailureThresholdを設定することがあります
  2. Readiness Probes(準備完了プローブ):

    • これらのプローブは、コンテナがトラフィックを受け付ける準備ができているかどうかを示します。すべてのコンテナが準備完了しているとき、Podは準備完了と見なされます。この情報は、どのPodをServicesのバックエンドとして使用するかを決定するために使用されます。Podが準備完了でない場合、Serviceのロードバランサから削除されます
    • Kubernetesは、準備完了プローブを使用してコンテナの健康を継続的に監視し、それらが受信トラフィックを処理する準備ができていることを確認します
  3. Startup Probes(起動プローブ):

    • 起動プローブは、コンテナアプリケーションが起動したかどうかを知るために使用されます。プローブが設定されている場合、生存および準備完了プローブは、起動プローブが成功するまで開始されません。これにより、これらのプローブがアプリケーションの起動を妨げないようにします。これは、起動が遅いコンテナで生存チェックを採用するために使用でき、kubeletによって完全に運用可能になる前に終了されるのを防ぎます
    • 起動プローブは、Kubernetesのバージョン1.16でアルファ機能として導入され、バージョン1.18でベータにアップグレードされました

これらのプローブはそれぞれ特定の目的を果たし、Kubernetesクラスタ内のアプリケーションの所望の運用状態を維持するのに寄与します。これらのプローブは、監視するアプリケーションの特定のニーズと動作に合わせて設定でき、Kubernetes環境内のサービスの耐障害性と可用性を向上させます。

Aurora リードポイント

インスタンス1台しかない場合の挙動

クラスターに 1 つ以上の Aurora レプリカが含まれている場合、リーダーエンドポイントは Aurora レプリカ間で各接続リクエストをバランスします。その場合、そのセッションでは SELECT などの読み取り専用ステートメントのみを実行できます。クラスターにプライマリインスタンスのみが含まれていて、Aurora レプリカが含まれていない場合、リーダーエンドポイントはプライマリインスタンスに接続します。その場合は、エンドポイントを介して書き込みオペレ―ションを実行できます。

とのことなので、ライター1台だけのクラスターでリーダーエンドポイントに接続するとライターに接続するし書き込みもできる

blog.serverworks.co.jp

dev.classmethod.jp

docs.aws.amazon.com

DMSタスク作成

各タスクには、データベース移行の必要に応じて設定できる設定があります。これらの設定はJSONファイルで作成するか、一部の設定で AWS DMS コンソールを使用して指定できます。

マネジメントコンソールで編集できる設定は一部… タスクの編集、ターゲットテーブルの準備モード、タスクの停止、LOB設定、検証、ログ記録の値

docs.aws.amazon.com

docs.aws.amazon.com

ERROR: null value in column violates not-null constraint

AWS DMS が LOB 列を移行する場合、LOB 列を除くすべてのデータがターゲットテーブルに移行されます。AWS DMS はまた LOB 列に NULL レコードを挿入します。次に、AWS DMS はターゲットテーブルの行を LOB 列データで更新します。

NULLレコードをinsertしてからupdateする挙動なのでNOT NULL制約があるとエラーになるらしいが、制限付きLOBモードだとNULL制約許可なのはよくわからない

|LOB モード| 全ロード |変更データキャプチャ| |完全 LOB モード |NOT NULL 制約は許可されていない |NOT NULL 制約は許可されていない| |制限付き LOB モード| NULL 制約は許可されている| NOT NULL 制約は許可されていない|

repost.aws

docs.aws.amazon.com