インプレースアップグレードと移行 (並行アップグレード) の 2 通りの方法が選択肢になる。
それぞれの特徴についてまとめる
セッションレスアプリケーション用に設計されている。
ローリングデプロイメントスケジュールを実装することにより、ステートフルアプリケーションにインプレースアップグレード方式を引き続き使用することができる。
Windows のサーバに十分なストレージがあることを確認する必要がある。
アップグレードのエラーや問題がより少ない反面、インプレースアップグレードより時間がかかる。
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/WindowsGuide/serverupgrade.html
Amazon Redshiftワークロード管理（WLM）を使用すると、
ユーザーはワークロード内の優先順位を柔軟に管理することができる。
これによって短時間で高速に実行されるクエリが、長時間実行されるクエリの背後にあるキューによって処理がつまることがなくなる。
よって、ワークロード管理によって部門の違うワークロード処理を分割するという戦略を取ることができる。
内部システムキューやユーザーがアクセス可能なキューなど、さまざまなタイプのキューの構成パラメーターを定義するサービスクラスに従って、実行時にクエリキューを作成する。
レプリカを起動させることで、高パフォーマンスを実現することはできない。
Redshiftのクエリのパフォーマンスを向上させる、または CPU、メモリ、I/O の過度の使用率に対応する場合、AWS マネジメントコンソールから Elastic リサイズを使用して、または ModifyCluster API を使用してデータウェアハウスクラスター内のノード数を増やすことになる。
Amazon Redshift の機能の “同時実行スケーリング” は、数千の同時実行クエリに対応する場合でも一貫して高速のクエリパフォーマンスを提供する。
この機能を使用すると、Amazon Redshift によって必要に応じて一時的な容量が自動的に追加され、大量の需要を処理することができるようになる。
キャッシュなのでどちらを選んでも一応動くことは動くのだが、それぞれのサービスの特化した機能について整理する。
アルタイム処理に利用するのに最適なサービス。
適切なユースケースとして適切なデータストレージを使用し、データアクセスパターンを考慮することで、パフォーマンスが大幅に向上するだけでなく、費用対効果の高いソリューションも提供することができる。
リアルタイムデータの計算処理を改善するためには最適なソリューション。
データをミリ秒で検索できる、オープンソースの分散型メモリ内キー値ストア。
セッションデータ管理など単純な処理を高速化する際は Memcachedの方が運用が容易であり望ましいユースケースになる。
似たように感じるサービスでもあるため、整理する
暗号化キーを簡単に作成して管理し、幅広い AWS のサービスやアプリケーションでの使用を制御できるようになります。（中略）AWS KMS は AWS CloudTrail と統合されており、すべてのキーの使用ログを表示できるため、規制およびコンプライアンスの要求に応えるために役立ちます。
https://aws.amazon.com/jp/kms/
クラウドベースのハードウェアセキュリティモジュール (HSM) です。これにより、AWS クラウドで暗号化キーを簡単に生成して使用できるようになります。
https://aws.amazon.com/jp/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に アクセス出来ない。
AWS Database Migration Service を使用すると、データベースを短期間で安全に AWS に移行することができる。
以下２点はとても大きな特徴だ
DMS についてまとめた。
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/
必要なメタデータ定義を含むターゲットテーブルが自動的に作成されてロードされるため、継続的なレプリケーションを指定できる。
ただし、以下の仕様を理解する必要がある。
あまり馴染みのないサービスの一つ Amazon Rekognition Video について調べた。
Amazon Rekognition Video は ライブビデオストリーミング をリアルタイムで解析して、顔を検出し、判別することができる。
Amazon Rekognition には、Amazon Rekognition API、AWS マネジメントコンソール、および AWS コマンドラインインターフェイス (CLI) を使用してアクセスすることが可能。
コンソール、API、CLI では、Rekognition API を使用して、ラベル検出、顔分析、顔照合、顔検索を行える。
AWS Lambda には Rekognition 用の設計図が用意されている。
それを使うことで s3 や DynamoDB といった AWS データストアでのイベントに基づいて画像分析をすることができる。
Amazon Rekognition Videoは、Amazon Kinesis Video Streamsを使用してビデオストリームを受信および処理する。
分析結果は、Amazon Rekognition VideoからKinesisデータストリームに出力され、クライアントアプリケーションによって読み取られる。
Amazon Rekognition Videoは、ストリーミングビデオの分析を開始および管理するために使用できるストリームプロセッサ（CreateStreamProcessor）を提供する。
分析結果はKinesis Data Streams Consumerに読み取られる。（Kinesis Data Streams Analyticsではない）
また、本題とは異なるが、以下のサービスについて補足
リアルタイムのストリーミングデータを簡単に収集、処理、分析できる。
コスト効率よくストリーミングデータを処理するための重要な機能を提供。
設定としては、Kinesis Agent を設定してデータを収集し、
Amazon Kinesis Data Firehoseを使用してエンドツーエンドのデータ配信ストリームを作成する。
その上で、
Amazon Kinesis Data Analytics で SQL クエリを使用してリアルタイム分析を実施することができる。
Amazon Kinesis Data Streams によって処理されたレコードはダッシュボードに送信されて、さまざまなAWSサービスへのデータ送信に使用できる。
分析するアクションとして、アプリケーション側にAmazon Kinesis Client Library（KCL）ワーカーを組み込んで行動分析を実施することができる。
また、Amazon Kinesis Data Streamsアプリケーションは、Amazon Kinesisストリームからデータをデータレコードとして読み取る。
これらのアプリケーションはAmazon Kinesis Client Library（KCL）を使用することでAmazon EC2インスタンスで実行するデータ分析アプリケーションを作成することができる。
Amazon Kinesis Data Analytics は、ストリーミングデータの分析に利用するサービス。Amazon Kinesis Data Analytics を利用すると、ストリーミングアプリケーションを構築し、管理し、AWS のサービスと統合する作業がシンプルになる。
Amazon Kinesis Data Analyticsを利用して、ストリーミングアプリケーションを構築し、管理し、AWS のサービスと統合する作業が実施できる。
SQL クエリを使用してリアルタイム分析を実施することができる。
s3 のバージョン管理を有効した場合の振る舞いについて整理する。
そもそもバージョニングとは、同じバケット内でオブジェクトの複数のバージョンを保持する手段。
バージョニングを使用して、Amazon S3 バケットに格納されたあらゆるオブジェクトのあらゆるバージョンを、格納、取得、復元することができるようになる。
バージョニングを使用すれば、アプリケーション障害からも、簡単に復旧でき流。
S3バージョン管理を有効にすると、既存のファイルはすべて、バージョンIDがNULLになる。
バージョン管理後に追加されると、そのファイルの バージョンIDは ランダム値が割り振られる。
公式ドキュメントは以下の通り
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/Versioning.html
以下の２つの要件を満たしたい時がある
CloudFront ウェブディストリビューションを活用する。
CloudFront ウェブディストリビューションを使うことで配信しているコンテンツに対し特定地域のユーザーによるアクセスを回避することができる。地域制限を使用するには、次の 2 つの方法が考えられる。
・CloudFront の地理制限機能の使用
エッジロケーションによる地理的制限を有効化。
ディストリビューションに関連するすべてのファイルへのアクセスを制限し、国レベルでアクセスを制限する場合は、この方法を使用する。
これをすると、S3 の公開しているバケットの中のファイル全てに制限をかけることができる。特定のファイルにのみ制限をかけることはできない。
・サードパーティの位置情報サービスの使用
上記 CloudFront の地理制限機能を使って要件を満たすことができない場合は、サードパーティのツールを探すことになる。
なお、Lambda＠エッジを利用した制限アルゴリズムを連携するといった機能は現状存在しない。
ネットワークACLはURLに基づいてリクエストをフィルター処理できない。
プロキシサーバーを利用して制御することで回避が可能。
プロキシサーバーはクライアントからの要求をフィルターし、製品の更新に関連する要求のみを許可するため、製品の更新以外のすべての要求のフィルターすることができる。
プロキシサーバーとは、内部ネットワークのセキュリティを損なわずにネットワークの外部と接続できるようにする、LAN 上のコンピューターを指す。
プロキシサーバーは内部コンピューターのアイデンティティを保護するために一般的に使用される。
プロキシサーバーは、内部ユーザーおよびサーバーからの要求の仲介役として機能して、多くの場合はコンテンツをキャッシュして後続の要求を高速化する。
AWSではVPNまたはAWS Direct Connect接続を使用して既存の企業プロキシサーバーインフラストラクチャを活用したり、内部ELBを備えたSquidプロキシサーバーなどのソフトウェアを使用してAWSでフォワードプロキシファームを構築したりすることが一般的なユースケースになる。
独身の時や、結婚当初のまだ子供がいない時期であれば比較的走る時間を確保することはできたが、子供が生まれると走る時間を確保がとにかく難しくなる。
自分の時間も大事だし、子供との時間も大事。
どのように両立しようか考えたところ、バギーラン（ベビーカーラン）という結論に辿り着いた。
昔ハワイに旅行に行った時、ワイキキビーチをベビーカーを押しながら走るランナーを見た。それも１組、２組ではなく、結構いた。帰国後調べてみたらバギーランという名前が付けられて定着している事を知った。なんでも大会まであるそう。
結論から言うとほとんどいない。自分は１年近くやっているが未だ同じようにベビーカーを押して走っている人にすれ違ったことがない。
自分なりに考えてみると、安全上の理由と、他の人からの目線、必要な情報がインターネットにほとんど公開されていない。
バギーに乗せるのは他でもない最愛の我が子である。そのため、安全は絶対だ。
私は AirGuggy COCO というバギーを愛用しており、普通のベビーカーを持っていない。
これでバギーランをする際のメリットとして以下があげられる。
安全性に加え、大容量の収容スペースもあるので着替えなどもいれることができる。
この程度。途中公園で遊んだりすることもあるので着替え用の Tシャツは多めに持つことが多い。
子供用のお菓子はあくまでも子供がお腹が空いた際の緊急用として。
絶対に確保したいのが子供の安全性である。そのため公道、歩道で子供を乗せて走るのは絶対に避けたい。
安全性と利便性を考慮し、たどり着いたのが荒川河川敷だった。
荒川河川敷でバギーランをする理由として、サイクリング用に舗装された見晴らしの良い道路があるという点がある。東武スカイツリーライン、小菅駅から徒歩１〜２分で河川敷にでることができる。
海まで走ることもできるが、海まで走ろうとすると比較的上り降りの段差が多く発生する。段差が多いとその分バギーをブレーキかけたりする必要があるのであまりおすすめしない。
埼玉（川口）方面に走るメリット
赤丸の部分が橋があるポイント。
日差しが強くて休みたい場合、通り雨に遭った際も休むことができる。
この場所が非常に頻繁にあるので心強いポイントだ。
一人で走る場合とは違い、子供を押して走るので、ただでさえスピードは落ちるということもあるが、
そこに安全性を考慮するとなると、いつでも止まれる速さで走る必要がある。
早歩きと、ランニングの中間的な速さ。1km あたり6分~ 7分程度が子供と会話しながら走るのにちょうど良い。
約7km の距離。
都市農業公園はサイクリストにも人気のある公園で、軽食も取ることができるし、テラスで休憩することもできる。
メニューは以下の通り。プチパンは子供でも食べれる。
なお、都市農業公園から西新井駅までバスも出ている。
約9km 程度。
9km まで走り、その後2km ほど公道を歩くと戸田の、七福の湯という温泉がある。
http://www.shichifukunoyu.jp/toda/
ここをゴールに設定するというのもいいコースになる。
3歳から有料だが、3歳未満だと無料で入ることができる。
なお、七福の湯付近で巡回パスが通っており、戸田公園駅まで 100円でバスに乗ることができる。
バスの時刻表は以下の通り。30分に一度はしっている。待ち時間が発生するようであれば、近くのララガーデンで時間を調整することもできる。
また、戸田公園駅では新幹線も見れるので子供も楽しめる。
以上、子供と楽しむバギーラン（ベビーカーラン）まとめ。
新しいコースを開拓したらアップデートしていこうと思う。