1 Minute Tips

カテゴリー: tech

  • IPSec VPN の特徴

    デフォルトで Amazon VPC 内に起動されるインスタンスと、ユーザー独自のネットワークとの通信はできない。

    VPC から独自のネットワークへのアクセスを可能にするには、以下のアプローチが必要になる。

    1. 仮想プライベートゲートウェイを VPC に関連付ける
    2. カスタムルートテーブルを作成
    3. セキュリティグループ規則を更新
    4. AWS Site-to-Site VPN接続を作成する

    Site-to-Site VPN は、インターネットプロトコルセキュリティ (IPsec) VPN 接続をサポートしている。 

    IPSecの特徴

    • Site-to-Site VPN 接続は、AWS Classic VPN または AWS VPN のいずれか。
    • IPSecトンネル経由で送信されるデータの整合性を保持する。
    • IPSecトンネルを経由して送信されるデータは暗号化される。
    • IPSecはインターネット経由で送信中のデータを保護する。
    • IPSecトンネルのセットアップ中にIDが認証される。
    • VPNゲートウェイ（VPG）とカスタマーゲートウェイ（CGW）の間にIPSecトンネルが確立される。

    データは暗号化されるが、SSLを利用してはいるわけではないと言うのは大きな特徴だ。

    参考情報

    IPsec-VPNとは？SSL-VPNとの違いもわかりやすく徹底解説！

    https://it-trend.jp/vpn/article/48-0063

  • AWS Elastic Beanstalk の deploy policy を整理する

    AWS Elastic Beanstalk は、デプロイポリシーも含めデプロイを処理するいくつかのオプションがある。

    All at once

    新しいバージョンをすべてのインスタンスに同時に展開する。

    環境内のすべてのインスタンスは、展開が行われている間、短時間サービスが停止することになる。

    そのため、展開に必要な合計時間を最短にする方法にはなる。

    Rolling

    Elastic Beanstalk は環境の EC2 インスタンスを複数のバッチに分割し、アプリケーションの新しいバージョンを一度に 1 つのバッチにデプロイする。

    そのため、環境内の残りのインスタンスは古いアプリケーションバージョンを実行した状態になる。

    つまりローリングデプロイ中は、アプリケーションの古いバージョンでリクエストを処理するインスタンスもあり、新しいバージョンでリクエストを処理するインスタンスも存在する。

    Rolling with additional batch

    新しいバージョンをバッチで展開するが、最初にインスタンスの新しいバッチを起動して、展開プロセス中に完全な容量を確保する。

    Immutable

    変更不可能な更新を実行して、古いバージョンを起動しているインスタンスと並行しながら、別の Auto Scaling グループにあるアプリケーションの新しいバージョンを起動している新しいインスタンスのフルセットを起動する。

    部分的に完了したローリングデプロイにより発生する問題を防止することができる。

    新しいインスタンスがヘルスチェックをパスしなかった場合、Elastic Beanstalkはそれを終了し、元のインスタンスをそのまま残す。

    参考情報

    https://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/using-features.rolling-version-deploy.html

  • AWSアカウントを跨いで S3 などを共有する

    リソースベースポリシーのクロスアカウントアクセスを設定することで対応が可能。

    一部の AWS サービスでは、リソースに対するクロスアカウントアクセス許可を付与することができる。

    クロスアカウントの理論についてはこちら

    https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html

    これを行うには、プロキシとしてロールを使用するのではなく、

    共有するリソースに直接ポリシーをアタッチすることになる。

    共有するリソースは、リソースベースのポリシーをサポートしている必要がある。

    なお、リソースベースポリシーが有効になっているサービスは

    • S3
    • SNS
    • SQS

    のみ。

    https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_compare-resource-policies.html

    ユーザーベースのポリシーとの違い

    端的に言うと、ユーザーに割り当てるのではなく、サービスに割り当てるもの。

    リソースベースポリシーは Principal が必須となる。

    公式のスライドはこちら

    https://www.slideshare.net/AmazonWebServicesJapan/20150617-aws-blackbeltiam

    公式ドキュメントはちょっと難解なので、Classmethod さんの記事が非常にわかりやすく噛み砕かれていた。

    https://dev.classmethod.jp/articles/aws-iam-policy/

  • Lambda カスタム統合/Lambdaプロキシ統合 について

    API Gateway と Lambdaファンクションを統合して実行するための方法は

    • Lambda カスタム統合
    • Lambdaプロキシ統合

    の２つあるのでそれぞれ整理する

    Lambda カスタム統合

    プロキシ統合のセットアップ手順に加えて、

    受信リクエストデータがどのように統合リクエストにマッピングされるか、
    統合レスポンスデータの結果がメソッドレスポンスにどのようにマッピングされるかを指定す。

    https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/set-up-lambda-custom-integrations.html

    Lambda プロキシ統合

    おそらく、API GW + lambda の構成の場合最も使われている機能だと思う。

    API にコンテンツのエンコーディングやキャッシュが不要な場合は、

    統合の HTTP メソッドを POST に設定し、統合エンドポイント URI を特定の Lambda 関数のアクションを呼び出す Lambda 関数の ARN に設定することで、認証情報を API Gateway がユーザーに代わって Lambda 関数を呼び出すことを許可する。

    https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html

  • AWS OrganizationsのSCP の落とし穴

    概要

    AWS Organizationsのサービスコントロールポリシー (SCP) は、組織を管理するために使用できるポリシーのタイプ。

    特徴

    SCP は、組織内のすべてのアカウントの最大使用アクセス権限を一元的に管理できる機能を提供し、アカウントが組織のアクセスコントロールガイドラインに沿って活動することを確実にする。

    SCP は、すべての機能が有効になっている組織でのみ使用できる。

    SCPはサービスにリンクされたロールには影響しないようになっているという特徴がある。

    IAMロール をインスタンスにアタッチしているなどの場合は、SCPによって制限することはできない。

  • EC2 で動いている Windows Server をアップグレードについて

    インプレースアップグレードと移行 (並行アップグレード) の 2 通りの方法が選択肢になる。

    それぞれの特徴についてまとめる

    インプレースアップグレード

    セッションレスアプリケーション用に設計されている。

    ローリングデプロイメントスケジュールを実装することにより、ステートフルアプリケーションにインプレースアップグレード方式を引き続き使用することができる。

    Windows のサーバに十分なストレージがあることを確認する必要がある。

    並行アップグレード

    アップグレードのエラーや問題がより少ない反面、インプレースアップグレードより時間がかかる。

    公式ドキュメント

    https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/WindowsGuide/serverupgrade.html

  • Amazon Redshiftワークロード管理（WLM）について

    Amazon Redshiftワークロード管理（WLM）を使用すると、

    ユーザーはワークロード内の優先順位を柔軟に管理することができる。

    これによって短時間で高速に実行されるクエリが、長時間実行されるクエリの背後にあるキューによって処理がつまることがなくなる。

    よって、ワークロード管理によって部門の違うワークロード処理を分割するという戦略を取ることができる。

    Amazon Redshift WLMについて

    内部システムキューやユーザーがアクセス可能なキューなど、さまざまなタイプのキューの構成パラメーターを定義するサービスクラスに従って、実行時にクエリキューを作成する。

    Amazon Redshift について注意すべきポイント

    レプリカを起動させることで、高パフォーマンスを実現することはできない。

    Redshiftのクエリのパフォーマンスを向上させる、または CPU、メモリ、I/O の過度の使用率に対応する場合、AWS マネジメントコンソールから Elastic リサイズを使用して、または ModifyCluster API を使用してデータウェアハウスクラスター内のノード数を増やすことになる。

    Amazon Redshift の機能の “同時実行スケーリング” は、数千の同時実行クエリに対応する場合でも一貫して高速のクエリパフォーマンスを提供する。

    この機能を使用すると、Amazon Redshift によって必要に応じて一時的な容量が自動的に追加され、大量の需要を処理することができるようになる。

  • ElastiCache を Redis / Memcached どちらを選ぶべきか

    キャッシュなのでどちらを選んでも一応動くことは動くのだが、それぞれのサービスの特化した機能について整理する。

    Amazon ElastiCache for Redis の特徴

    アルタイム処理に利用するのに最適なサービス。

    適切なユースケースとして適切なデータストレージを使用し、データアクセスパターンを考慮することで、パフォーマンスが大幅に向上するだけでなく、費用対効果の高いソリューションも提供することができる。

    リアルタイムデータの計算処理を改善するためには最適なソリューション。

    Amazon ElastiCache for Memcached の特徴

    データをミリ秒で検索できる、オープンソースの分散型メモリ内キー値ストア。

    セッションデータ管理など単純な処理を高速化する際は Memcachedの方が運用が容易であり望ましいユースケースになる。

  • AWS KMS と CloudHSM について整理する

    似たように感じるサービスでもあるため、整理する

    KMS

    暗号化キーを簡単に作成して管理し、幅広い AWS のサービスやアプリケーションでの使用を制御できるようになります。（中略）AWS KMS は AWS CloudTrail と統合されており、すべてのキーの使用ログを表示できるため、規制およびコンプライアンスの要求に応えるために役立ちます。

    https://aws.amazon.com/jp/kms/

    CloudHSM

    クラウドベースのハードウェアセキュリティモジュール (HSM) です。これにより、AWS クラウドで暗号化キーを簡単に生成して使用できるようになります。

    https://aws.amazon.com/jp/cloudhsm/

    両サービスとも暗号化キーの生成できるようだ。

    ユースケースに分けて整理する。

    KMS のユースケース

    サーバにアクセスする際の共通鍵の管理など

    CloudHSM のユースケース

    データの暗号化に使用されるSSLキーの安全性を確保する際に使う

    CloudHSMを使用し、アプリケーションサーバーログがサーバーサイド暗号化（SSE）を使用してS3バケットに保持する仕組み作る。

    CloudHSMは、アプリケーションログが永続的かつ安全に保存されるようになる。

    正確に理解しておくべきポイント

    AWS KMSはAWS CloudHSMのようにSSL処理をオフロードするといった対応はできない

    実は公式にもこれら２つのサービスについての記載がある

    https://aws.amazon.com/jp/kms/faqs/

    black belt ではもう少しわかりやすく整理されている

    https://d1.awsstatic.com/webinars/jp/pdf/services/20190723_AWS-Blackbelt-CloudHSM.pdf

    AWS KMSはAWS CloudHSMのようにSSL処理をオフロードするといった対応はできないという点は大きな特徴になる。

    https://docs.aws.amazon.com/ja_jp/cloudhsm/latest/userguide/ssl-offload-overview.html

    サポートする暗号鍵も違う

    KMS の場合共通鍵のみだが、CloudHSM の場合、共通鍵と公開鍵がサポートされている。

    VPC内で稼働するサービス : VPC外からアクセスする場合には、CloudHSMがあるVPCにルーティングする必要があるようだ。

    CloudHSM はリージョン内で稼働するサービス になる。 異なるリージョンからはCloudHSMに アクセス出来ない。

  • Amazon Database Migration Service (DMS) を使った移行について

    概要

    AWS Database Migration Service を使用すると、データベースを短期間で安全に AWS に移行することができる。

    以下２点はとても大きな特徴だ

    • 移行中でもソースデータベースは完全に利用可能な状態に保たれる
    • データベースを利用するアプリケーションのダウンタイムを最小限に抑えられる

    DMS についてまとめた。

    DMS を使った Database Migration をする際の流れ

    1. ソースデータベースからターゲットデータベースにデータを割り当てる。
    2. 移行するタスクを実行するのに十分なストレージと処理能力を持つレプリケーションインスタンスを作成する

    AWS DMSタスクは、すべての処理が行われる場所になる。ここで

    • ログ記録要件
    • 制御テーブルデータ
    • エラー処理

    など、移行と特別な処理に使用するテーブルとスキーマを指定することができる。

    タスクを設定方法について

    移行タスクを作成する前に、DMSコンソールで以下３つを作成する。

    • ソースエンドポイント
    • ターゲットエンドポイント
    • レプリケーションインスタンス


    移行タスクを調整するために多くのタスク設定を指定することが可能だ。

    AWS マネジメントコンソール、 AWS CLI、または AWS DMS API を使用して設定する。

    これらの設定には、以下の項目を変更することが可能

    • 利用するテーブル構成
    • レプリケーションプロセス
    • 移行エラーの処理方法
    • エラーのログ記録
    • および制御テーブル情報を指定

    移行のタイプは “migrate existing data and replicate ongoing changes (初期転送後、差分転送開始)”を指定すると、タスクを作成した後、直ちに実行できる。

    この点は Classmethod のブログが非常にわかりやすい。

    https://dev.classmethod.jp/articles/lets-try-aws-database-migration-service-dms/

    必要なメタデータ定義を含むターゲットテーブルが自動的に作成されてロードされるため、継続的なレプリケーションを指定できる。

    ただし、以下の仕様を理解する必要がある。

    • デフォルトではタスクを作成するとすぐに、AWS DMS によりタスクが開始される。
      ただし、タスクの開始を延期することが可能。
    • ・AWS DMS コンソール、AWS CLI、または AWS DMS API を使用して、タスクのモニタリング、停止、再開を行うことができる。