前言 役に立つ情報のまとめです １.料金と構築の検討 (１) クラウド構成と料金試算例一覧 アマゾン ウェブ サービス（AWS）は、開発環境としてはもちろん、ウェブサイト・ウェブアプリケーションからファイルサーバー、社内業務アプリケーション、動画配信、IoT、AI/機械学習までにいたるまで、数多くの用途で活用されています。 (２) S3 Transfer Acceleration - Speed Comparison リージョンにより、アップロード速度を比較・検討するためのサイト (３) サーバーレスアプリケーション向きのDB 設計ベストプラクティス AWSセミナー資料 ２.事例 AWSお客様事例の検索 さまざまな規模のお客様が AWS を使用して、アジリティの向上、コストの削減、そしてイノベーションの推進をクラウドで実現した方法を紹介します。 (１) 株式会社テレビ東京 - 映像コンテンツの保管 問題・課題 メディアの運用とコストの負荷肥大 対応 Amazon S3 / S3 Glacier へ移行 効果・結果 ① メディア調達コストを数千万円 / 年削減 ② Direct Connect で回線の安全性と冗長性を確保 ③ AI 映像解析を検証、社内データ連携も検討 (２) 朝日放送株式会社　- 『M-1グランプリ』敗者復活戦投票システム 問題・課題 視聴者投票の実施と集計を⾏うシステムの構築 対応 サーバレスアーキテクチャのWEBシステムの構築 効果・結果 ① 自社社員2名のみ、かつ開発期間わずか43日で構築が可能になった（検証期間9日） ② 少ない学習コストで実現したいシステムを構築できた ③ 少ない作業コストでシステム運用が可能になった (３) PayPay 問題・課題 通知サービスの検討 対応 各DBの検討・DynamoDB活用 効果・結果 ① 運用作業の削減 ② 開発が簡単に (４) DeNA - インフラノウハウの発信プロジェクト連載まとめ 問題・課題 システム全体 対応 ① Auto Scalingの構成 ② スポットインスタンスの活用 ③ MySQLサーバのMulti Instance化 ④ GCP プロジェクトの利用 効果・結果 ① 大幅なコスト削減を達成しました（インフラコスト 60% 削減） ② 「最高品質のインフラ」を「提供までのリードタイムを短くしたまま」で提供できた (５) ZOZO 問題・課題 ネットワークの構築と管理 対応 ネットワークの構築と管理にAWS CloudFormationとAWS OpsWorksを導入 効果・結果 ① 再利用性の向上 ② ノウハウの蓄積 ③ 履歴管理が可能 (６) 東宝株式会社 - サイトでの情報配信 問題・課題 各サイトで個別管理するのは高負荷 対応 Amazon CloudFrontの導入 効果・結果 ① アクセス集中の解決 ② 半月足らずの期間で、構成の設計から構築まで完了 (７) The Pokémon Company - モバイルゲーム 問題・課題 扱っているデータは複雑で大量 対応 AWS 専用データベースに移行 効果・結果 ① 月額費用を数万ドル削減 ② ノード数を 300 から 30 に削減 ③ ボットのログイン試行を 90% 削減 ④ データベースのライセンスコスト排除 ⑤ 移行後のダウンタイムまたはパフォーマンスの低下は一切なし ⑥ 1 秒あたり最大 300 件のログインを処理 (８) クックパッド株式会社 - クックパッド 問題・課題 システム全体 対応 ① 運用開発の体制（CloudTrail、Config） ② クックパッドの機械学習基盤（AMI、Lambda、CloudWatch、SQS、S3、ECS） 効果・結果 ① セルフサービス化・トレースできる仕組みづくり ② エンタープライズサポートの活用 ③ GPU計算機環境の構築 (９) 株式会社スクウェア・エニックス - ゲームに連動するポータルサイトやスマートフォン用のアプリケーション 問題・課題 ① お客様が撮影される写真は膨⼤な数 ② 画像加工はちょっと重たい処理 ③ イベントなどで撮影が集中すると、サーバー負荷のスパイクが発生します 対応 AWS S3と Lambdaの導入 効果・結果 ① 数時間かかっていた画像処理がわずか 10 数秒で完了しました。 ② コスト、人的リソースの削減 ３.設計書・報告書関連 AWS アーキテクチャアイコン アーキテクチャダイアグラムは、設計、デプロイ、トポロジーを伝達する手段として優れています。このページでは、AWS 製品アイコン、リソース、およびダイアグラムの作図に役立つその他のツールを含む AWS アーキテクチャアイコン (旧称シンプルアイコン) の公式セットをご覧いただけます。 draw.io、 ４.セミナー・カンファレンス・イベント関連 (１) Re.Invent AWS のクラウドサービスに関わる技術的なセッション・ハンズオンなどを提供しており、お客様が主体的に体験できる学習機会が豊富な AWS 最大のラーニングカンファレンスです。 (２) Amazon Web Services Japan 公式（Youtube） Re.Inventやセミナーの動画を再生できます (３) AWS イベントスケジュール アマゾン ウェブ サービスの最新情報・事例、利用方法等の情報が取得できる、 様々なイベントの最新スケジュールをご紹介しています。 (４) AWS クラウドサービス活用資料集トップ アマゾン ウェブ サービス (AWS) は安全なクラウドサービスプラットフォームで、ビジネスのスケールと成長をサポートする処理能力、データベースストレージ、およびその他多種多様な機能を提供します。お客様は必要なサービスを選択し、必要な分だけご利用いただけます。それらを活用するために役立つ日本語資料、動画コンテンツを多数ご提供しております。(本サイトは主に、AWS Webinar で使用した資料およびオンデマンドセミナー情報を掲載しています。) (５) セミナー講義 パワーポイント資料 ５.その他 (１) ポリシージェネレータ S3、SQS、VPC、IAM、SNSのポリシーが作成できます。 (２) S3 オブジェクトのアップロード方法 S3 コンソール、AWS SDK、REST API、AWS CLI (３) S3 オブジェクトのアップロードツール - CloudBerry Explorer Freeware for Amazon S3 Manage files across your local storage and S3 buckets

まとめた本のタイトル AWSコンテナ設計・構築［本格］入門 目的 AWSのコンテナサービスを理解し、開発環境を取り巻く技術動向に対し順応できるようにするため。 ※この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。 1章 この章ではコンテナとそれを扱うソフトの理解を目的としている。 【コンテナとは】 他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術 【コンテナ利用のメリット】 ・環境依存からの解放 コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。 依存関係を含めたパッケージがリリース単位となる ・環境構築やテストに要する時間の削減 優れた再現性とポータビリティ。 全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。 ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。 ・リソース効率のアップ サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。 一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に１つのプロセスが稼働している扱いになる。 【Dockerとは】 コンテナのライフサイクルを管理するプラットフォーム アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。 アプリのソースコード + Dockerfile ↓ buildでイメージの作成 イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS) ↓ ship でイメージの保存 レジストリに保存 ↓ run　コンテナの実行 オンプレやクラウドなどで起動 【Dockerfileとは】 イメージを構築するためのテキストファイル。 このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。 1章まとめ、感想 コンテナの登場により、本番・開発環境ごとにサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。 2章 この章ではコンテナサービスをコントロールプレーン、データプレーンという概念を切り口として、コスト、拡張性、信頼性、エンジニアリングを論じていく。ここではECS Fargateに話を絞って書き、他は割愛する。 AWSが提供するコンテナサービス コントロールプレーン ・コンテナを管理する機能 コントロールプレーンは2種類 ECSとEKSがある。 ECS フルマネージドなコンテナオーケストレータ。 オーケストレーションサービスであり、コンテナの実行環境ではない。 ECSの月間稼働率は99.99%であることがSLA として保証。 タスク コンテナが動作するコンポーネント。 タスクは1つ以上のコンテナからなる アプリを起動するためにはコンテナが必要。 タスク定義 タスクを作成するテンプレート定義。JSONで記述。 デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。 サービス 指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。 クラスター サービスとタスクを実行する論理グループ データプレーン コンテナが実際に稼働するリソース環境 2種類ありECSとFargateがある。 Fargateに絞って書く Fargateとは サーバーレスコンピューティングエンジン AWSのフルマネージドなデータプレーンとして定義されている コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する Fargate メリット ホスト管理が不要であること サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる Fargate デメリット ・価格がEC2より高い。 ・利用者がコンテナの稼働するOSには介入できない ・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる ECR フルマネージドなコンテナレジストリ コンテナイメージを保存、管理できる コンテナが利用されているサービス ・Lambda ・App Runner Lambda 　利用者がコードをアップロードするだけでコードを実行できるサービス。AWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス。 App Runner 　2021年5月にGA(一般公開)となったサービス。プロダクションレベルでスケール可能なwebアプリを素早く展開するためのマネージドサービス。Githubと連携してソースコードをApp Runnerでビルドとデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。 　ECSとFargateの場合、ネットワークやロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識は必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である。 ECS Fargateを利用した場合のコスト、拡張性、信頼性、エンジニアリング観点 【コスト】 EC2より料金は割高。ただし、年々料金は下がってきている。 【拡張性】 デプロイの速度　遅め 理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる 理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。 タスクに割り当てられるエフェメラルストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要な場合はEFSボリュームを使う手もある。 割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリを要求するホストとしては不向き 【信頼性】 Fargateへのsshログインは不可。Fargate上で起動するコンテナにsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境にsshの口を開けるのはリスキーである。他にSSMのセッションマネージャーを用いてログインする方法もあるが、データプレーンがEC2の時に比べると手間がかかる。 しかし、2021年3月にAmazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。 【エンジニアリング観点】 Fargateの登場からしばらく経過し、有識者や経験者は増え、確保しやすい。 ・システム要件の確認 多数のユーザーに使ってもらう 可用性を高めるためにマルチAZ構成を取る CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める 各レイヤで適切なセキュリティ対策（不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス）を施したい 2章まとめ、感想 AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。 3章 この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計という様々な設計観点から、どのサービスやオプションと連携することで高い目標を達成できるかについて述べている。 【運用設計】 Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。 モニタリングとは システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと オブザーバビリティとは システム全体を俯瞰しつつ、内部状態まで深掘できる状態 オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる 【ロギング設計】 ・cloud watch logs 他のAWSサービスとの連携も容易 サブスクリプションフィルターで特定文字列の抽出も容易 ・Firelens AWS以外のサービスやAWS外のSaaSと連携することも可能 Firehoseを経由してS3やRed shift やOpenSearch Serviceにログを転送できる Fluentdやfluent bitを選択できる fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる 【セキュリティ設計】 ・イメージに対するセキュリティ対策 　- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。 　- 方法 　　脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン 継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。 cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる（スキャン自体は1日1回のみ可能） ・提供元が不明なベースイメージの使用は避ける ・IAMポリシーによるECRのパブリック化の禁止 　- オペレーションミスによる公開を防ぐことができる 【信頼性設計】 ・マルチAZ構成 Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。 ・障害時切り離しと復旧 ECSはcloud watchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる ALBと結びつけることで、障害が発生したタスクを自動で切り離す ・リタイアという状態 AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。 Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。 ・システムメンテナンス時におけるサービス停止 ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能 ・サービスクォータという制限 意図しない課金増加から保護するために設けられた制限 自動でクォータは引き上がらない cloud watch メトリクスなどで監視する必要がある。 【パフォーマンス設計】 パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと ビジネス上の性能要件を把握することが前提 利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める 既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する ・スケールアウト サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。 スケールアウト時の注意 ・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。 ・VPCのIPアドレスの割当量に気をつける ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく。スケールアウトによるIPアドレスの枯渇に注意。 Application Autoscaling Fargateで使用可能 Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う ステップスケーリングポリシー ステップを設けて制御する CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる ターゲット追跡スケーリングポリシーとは 指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針 ターゲット追跡スケーリングポリシー メトリクスがターゲットの値を超えている場合のみスケールアウトする仕様となっている。下回っている場合のスケールアウトは定義不可 ターゲット追跡スケーリングポリシーは、スケールアウトは高速、スケールインは緩やかに実行される。 それは急激なスケールインによるサービス可用性への影響を抑えるためである。 ターゲット追跡スケーリングポリシーの良い点 利用者側でチューニングすべき事項が最小限であること。 コストとパフォーマンスのバランスがとれるところに収束すること 【コスト最適化設計】 ・ECRのコンテナイメージのメンテナンス コンテナのイメージサイズに応じて課金されるため、不要なイメージは削除することが望ましい ・開発環境やステージング環境の稼働時間帯の調整 24時間稼働している必要がなければcloud Watch eventから定期的にLambdaを起動し、ECSタスク数を調整することで、夜間の稼働をなくし、コスト削減に繋げられる 全体を通しての感想 　本に載っている環境と実際の現場での環境はやはり大きく異なっている。基本的なこと、やるべきことはもちろんそれほど変わらないが、現実のシステムはさまざまな制約・条件から大変複雑であり、その都度要求にあうものを考えていかなくてはならない。 　今回学んだことはあくまで基礎として吸収し、実際の現場で役立てられる場面ではそれを生かしていきたい。

権威DNSサーバーとフルサービスリゾルバの2種類があります。 権威DNSサーバーは、ゾーンという単位でドメイン名とIPアドレスを管理しています。 ゾーンの中には、レコードとという単位でドメイン名とIPアドレスを紐付ける情報を保持しています。 下表のレコードをリソースレコードと呼びます。 リソースレコード 説明 Aレコード address recordの略。ドメイン名とIPv4アドレスを紐付けるレコード AAAAレコード quad a recordとも呼ばれる。ドメイン名とIPv6アドレスを紐付けるレコード PTRレコード pointer recordの略。IPアドレスとドメイン名を紐付けるレコード NSレコード Name Serverレコードの略。他の権威DNSサーバーの場所を保持するレコード SOAレコード Start of authority recordの略。権威DNSサーバーのゾーンの情報を保持するレコード CNAMEレコード Canonical name recordの略。AレコードやAAAAレコードの別名を示すレコード エイリアスレコード Route53独自のレコード。CNAMEレコードと違い、別名からIPアドレスのように１回のクエリで取得できる。AWS内のリソースに限り指定できる。

はじめに 今回は、AWSの「データベースサービス」の概要について勉強した内容を紹介します。 「RDS」「DynamoDB」に絞って、その特徴をまとめていきます。 参考書籍 ※ 『AWS認定資格試験テキスト AWS認定クラウドプラクティショナー』 本記事は、本書の第8章に相当 項目 RDS DynamoDB 1. RDS Amazon RDSは、マネージド型リレーショナルデータベースで、データベースエンジンをAmazon Aurora、MySQL、MariaDB、Oracle、Microsoft SQL Server、PostgreSQLといった一般的な 6 種類のエンジンから選択できます。 つまり、既存のデータベースで現在既に使用しているコード、アプリケーション、ツールを Amazon RDS で使用できます。 Amazon RDSはプロビジョニング、パッチの適用、バックアップ、リカバリ、障害検知、リペアなど、データベースのルーティンタスクを処理します。 業界標準のリレーショナルデータベースにコスト効率の高いサイズ変更可能な容量を提供し、一般的なデータベース管理タスクを管理します。 ーAWSユーザーガイドより （1）概要 Amazon Relational Database Service(RDS）、リレーショナルデータベースを提供するサービスです。 「リレーショナルデータベース」とは、事前定義された、関連があるデータ項目の集合体です。 この項目は、列と行を持つテーブルのセットとして構成されます。テーブルは、データベースに表現されるオブジェクトに関する情報を保持するために使用されます。 イメージとしては、高機能なExcelのようなものです。 リレーショナルデータベースは、規模を問わずに利用されており、個人用途から大企業の社内システムまで、幅広いシーンで活躍しています。 Amazon Aurora、MySQL、MariaDB、Oracle、Microsoft SQL Server、PostgreSQLの６つを使用できます。 データベースのインストールやバックアップなどのセットアップをしなくても、データベースが利用できる環境が提供されているため、契約後すぐにAWS上でデータベースを使用することができます。 （2）EC2との違い Amazon Aurora以外は、EC2に各データベースエンジンをインストールして使用することができます。 主な違いは、使用メリットにあります。 オンプレミスでデータベースサーバーを構築する場合、電源・空調・ネットワーク回線・ラックスペースの確保・ラッキング・物理サーバーの管理・OSのインストール・データベースの管理全てを行わなければいけません。 EC2を起動したサーバーにデータベースエンジンをインストールする場合、物理要素やハードウェアとOSのインストールまではAWS側に任せることができます。 しかし、この場合だと、もしOSのモジュールに脆弱性が見つかったら、パッチの適用が必要です。 データベースのインストール・バックアップ・マイナーバージョンのバージョンアップ・複数のAZをまたいだ高可用性の確保などを手動で行わなければいけません。 RDSでデータベースエンジンを使用した場合、これらの管理は全て必要なくなります。 メンテナンス・バックアップ・高可用性について、AWS側で担保してくれます。 メンテナンスについては、週に１回、設定した時間に自動的に行ってくれますし、バックアップについては、デフォルトで７日間分の自動バックアップをしてくれます。 ※バックアップ期間は０〜35日間まで設定できますが、それ以上になると、スナップショットを作成する設定を行う必要があります。 ※RDSのバックアップ機能である「ポイントタイムリカバリー」を使えば、最大5分前までのリカバリが可能です。RDSの起動が完了したタイミングで、自動でトランザクションログが保存され始めます。 さらに、RDSは、「いつ壊れてもおかしくない（Design for Failure）」という原則で設計されているので、単一障害点とはなりません。 マルチAZ配置をオンに設定すると、AZをまたいでレプリケーションが自動で行われます。 レプリケーションとは、「複製（レプリカ）を作ること」の意味。同じネットワーク内、もしくは遠隔地にサーバーを設置し、リアルタイムにデータをコピーする技術のこと。マスターのデータベースと全く同じ内容のデータベースを作成できるため、負荷分散やホットスタンバイに有効な手段として普及している。 マスターに障害が発生しても、自動的にフェイルオーバーが行われます。 フェイルオーバーとは、稼働中のシステムで問題が生じてシステムやサーバーが停止してしまった際に、自動的に待機システムに切り替える仕組みのこと。 これらも、AWS側の責任で行われます。 Amazon Aurora、MySQL、MariaDB、PostgreSQLではリードレプリカを作成することができます。 これにより、読み込みの負荷をマスターデータベースから軽減できます。 他のリージョンにリードレプリカを作成することもでき、これを、クロスリージョンリードレプリカといいます。 （3）Amazon Aurora Amazon Auroraは、AWSがクラウドに最適化して再設計したリレーショナルデータベースエンジンです。 MySQL、PostgreSQLのモデルをサポートしています(MySQL、PostgreSQLを使用しているアプリケーションの場合、そのままAuroraを使うことができる)。 Auroraを利用すると、 ・ハードウェアのプロビジョニング、データベースのセットアップ、パッチ適用、バックアップといった時間のかかる管理タスクが自動化される ・リードレプリカは15個作成できる ・ストレージシステムは、分散型で耐障害性と自己修復機能を備えており、データベースインスタンスごとに最大128TBまで自動的にスケールされる ・MySQLに比べて5倍の性能、PostgreSQLと比べて3倍の性能 ・ディスク容量を見込で確保しなくても自動で増加してくれる ・商業用データベースと同等のパフォーマンスを、10分の1のコストで実現できる といったメリットがあります。 （4）DMS AWS Database Migration Service (AWS DMS)は、オンプレミスからAWS、または、AWSからAWSのデータベースの移行をする場合、迅速かつ安全に移行してくれる機能を持っています。 ざっくりいうと、オンプレミスや他社クラウドで稼働するDBを、AWSのあれこれへ簡単に移行させることができるツールです。 移行中でも、データベースは完全に利用可能な状態に保たれ、データベースを利用するアプリケーションのダウンタイムを最小限に抑えられます。 DMSへのデータ転送はすべて無料で、「RDS」や「EC2」と「DMS」との間のデータ転送も無料です。 なお、データベースを「Amazon Aurora」「Amazon Redshift」「Amazon DynamoDB」などに移行する場合は、無料で6ヶ月間利用できます。 AWS DMSを実行させるには、まず「レプリケーションインスタンス」を作成して、ソースおよびターゲットの「エンドポイント」を指定します。さらに、「タスク」を作成して移行を実行させる、という流れです。 どの手順も高度なスキルは不要で、単純な作業だけで済みます。 2. DynamoDB Amazon DynamoDBは、完全に管理されたNoSQLデータベースサービスであり、シームレスなスケーラビリティを備えた高速で予測可能なパフォーマンスを提供します。 DynamoDBを使用すると、分散データベースの運用とスケーリングの管理上の負担を軽減できるため、ハードウェアのプロビジョニング、セットアップと構成、レプリケーション、ソフトウェアのパッチ適用、またはクラスターのスケーリングについて心配する必要がありません。 DynamoDBは、保存時の暗号化も提供します。これにより、機密データの保護に伴う運用上の負担と複雑さが解消されます。 ーAWSユーザーガイドより （1）概要 Amazon DynamoDBは、ハイパフォーマンスなアプリケーションをあらゆる規模で実行するために設計された、フルマネージド、サーバーレスのNoSQLデータベースです。 NoSQLは非リレーショナルなデータベースを表す言葉で、「データベースの分類」を表します。 NoSQLはRDBのようにテーブル構造に固定することなく、さまざまな形式のデータをそのまま格納できます。 DynamoDBを使い始めるときは、テーブルの作成から始めます。 データベースサーバーとしてインスタンスを作成する必要はありません。 最低限の設定では、テーブル名とプライマリーキーを決めれば大丈夫です。 使用するときは、リージョンを選択することになります。 最初からマルチAZな環境になっているため、AZを意識する必要はありません。 使用時は、書き込みと読み込みのキャパシティユニットを設定することができます。これは、オートスケールさせることが可能です。 モバイル、ゲーム、IoT、大規模なWebシステムのバックエンド、サーバーレスアーキテクチャ、ジョブステータス管理、セッション管理、クリックストリームデータなど、様々なユースケースで使用されています。 データ容量は無制限で、使用容量に対して課金されます。 （2）RDSとの違い DynamoDBとRDSの大きな違いは、RDSはリレーショナルデータベースであり、DynamoDBはNoSQLであるところです。 RDSは、大量のデータ更新や読み込みを必要とする処理には向いていません。 垂直スケーリングによりスケールアップすることはできるものの、大量のアクセスに対しては低速での処理になってしまうのです。 しかし、DynamoDBでは、水平スケーリングによるスケールアップが可能なので、大量のアクセスやデータ処理があっても、性能を落とすことなく高速で処理を行うことができます。 ただ、RDSならばトランザクションを必要とする処理や複雑な処理ができるものの、DynamoDBではそういったことには向いていません。 また、データの構造も違います。 RDSはSQL型のテーブル形式ですが、DynamoDBはNoSQL型のテーブル形式です。 DynamoDBでは、一つのデータを「アイテム」として扱い、キーとして設定している属性と値さえあれば、それ以外は動的で自由なのです。 キーとバリューの組み合わせで作られるシンプルなデータモデルが基本だと考えてもらえらばいいでしょう。 画像・音声データなどの非構造データを大量に保持したい場合などに利用できます。 DynamoDBを使いたいときは、NoSQLは大量のデータ利用とシステムの柔軟性を実現したい場合に利用するのが良いと言えそうです。 参考サイト Amazon RDS アーキテクチャ概要 AWS Documentation Amazon RDSってなに？ AWSのデータベースAmazon RDSとは？ Amazon RDSの基本を解説、作成方法やAuroraでの利用のメリットを詳しく 5分でわかる「RDS」 AWS DMSとは？環境を構築する4つの流れとメリットを解説 NoSQL データベースとは リレーショナルデータベースとNoSQLデータベースの違いとは？ NoSQLとは？その特徴や利用するメリット、活用事例を解説 参考書籍 ※ 『AWS認定資格試験テキスト AWS認定クラウドプラクティショナー』 ● Amazonはこちら ● 楽天はこちら

このドキュメントは Mac上でCDK環境を整備する方法をまとめたものです 前提条件 使用PC 手順 homebrewでaws-cdkをインストールする % brew install aws-cdk ==> Downloading https://ghcr.io/v2/homebrew/core/node/manifests/17.4.0 Already downloaded: /Users/mukai/Library/Caches/Homebrew/downloads/794ea4ad96ad44757653ec3839632a88467cde669de3305f9d5f12ce1bd81769--node-17.4.0.bottle_manifest.json ==> Downloading https://ghcr.io/v2/homebrew/core/node/blobs/sha256:1954cb0ba19e7426054249eda70dff8bda197a960f4e0524af717245faa13529 Already downloaded: /Users/mukai/Library/Caches/Homebrew/downloads/66eb66783323a07fdee08e1e680a0c3cf4081301b4b5e2c706aaacadcbc01c5f--node--17.4.0.arm64_monterey.bottle.tar.gz ==> Downloading https://ghcr.io/v2/homebrew/core/aws-cdk/manifests/2.8.0 Already downloaded: /Users/mukai/Library/Caches/Homebrew/downloads/86f67ab001382e06f746a2028f74cd1b456fd42205fd9027bdc334462758c5cf--aws-cdk-2.8.0.bottle_manifest.json ==> Downloading https://ghcr.io/v2/homebrew/core/aws-cdk/blobs/sha256:d3b1acac013ab7e7d72dbca9e4c2e475d265eb0b7c4fcaeb1c19df92582bb98b Already downloaded: /Users/mukai/Library/Caches/Homebrew/downloads/2059e2a9adac14728af21d7f8d0328c3ddd5c329ec2d57c6a2db505e93197acf--aws-cdk--2.8.0.arm64_monterey.bottle.tar.gz ==> Installing dependencies for aws-cdk: node ==> Installing aws-cdk dependency: node ==> Pouring node--17.4.0.arm64_monterey.bottle.tar.gz ? /opt/homebrew/Cellar/node/17.4.0: 1,984 files, 44.5MB ==> Installing aws-cdk ==> Pouring aws-cdk--2.8.0.arm64_monterey.bottle.tar.gz ? /opt/homebrew/Cellar/aws-cdk/2.8.0: 9,755 files, 174.9MB ==> Running `brew cleanup aws-cdk`... Disable this behaviour by setting HOMEBREW_NO_INSTALL_CLEANUP. Hide these hints with HOMEBREW_NO_ENV_HINTS (see `man brew`). バージョン確認 正常に動いてはいるが、依存関係でインストールされたnodeのバージョンが新しいのでCDKは動作未確認とのこと。 % cdk --version !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !! !! !! This software has not been tested with node v17.4.0. !! !! You may to encounter runtime issues, and should switch to a supported release. !! !! !! !! As of the current release, supported versions of node are: !! !! - ^12.7.0 !! !! - ^14.5.0 !! !! - ^16.3.0 !! !! !! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 2.8.0 (build 8a5eb49) nodeのダウングレード cdkのコマンドを叩くたびにいちいちコーションが出るのは嫌なのでnodeをダウングレードする。 Homebrewでインストールされたnodeをアンインストールし、nodebrewでnodeを改めてインストールする。 % brew uninstall node Error: Refusing to uninstall /opt/homebrew/Cellar/node/17.4.0 because it is required by aws-cdk, which is currently installed. You can override this and force removal with: brew uninstall --ignore-dependencies node aws-cdkと依存関係があるのでアンインストールできないらしい。 指示に従って、オプションをつけてリトライ % brew uninstall --ignore-dependencies node Uninstalling /opt/homebrew/Cellar/node/17.4.0... (1,984 files, 44.5MB) できた。続いて、nodebrewインストール。 % brew install nodebrew ==> Downloading https://ghcr.io/v2/homebrew/core/nodebrew/manifests/1.1.0-1 Already downloaded: /Users/mukai/Library/Caches/Homebrew/downloads/f5786fdcabaf7a91171f3d803ecbb7b8d5d0fd7bd5f9f13a0fda7b7722b46af8--nodebrew-1.1.0-1.bottle_manifest.json ==> Downloading https://ghcr.io/v2/homebrew/core/nodebrew/blobs/sha256:f9e68ad3b92827534fc9faf5d7b9c4d1fe61e4e1fa11a99e03c6cc476593fe09 Already downloaded: /Users/mukai/Library/Caches/Homebrew/downloads/e570150909b477bae65e749b152e5d87aa71158439019f8e2309456f25cf9993--nodebrew--1.1.0.all.bottle.1.tar.gz ==> Pouring nodebrew--1.1.0.all.bottle.1.tar.gz ==> Caveats You need to manually run setup_dirs to create directories required by nodebrew: /opt/homebrew/opt/nodebrew/bin/nodebrew setup_dirs Add path: export PATH=$HOME/.nodebrew/current/bin:$PATH To use Homebrew's directories rather than ~/.nodebrew add to your profile: export NODEBREW_ROOT=/opt/homebrew/var/nodebrew zsh completions have been installed to: /opt/homebrew/share/zsh/site-functions ==> Summary ? /opt/homebrew/Cellar/nodebrew/1.1.0: 8 files, 39KB ==> Running `brew cleanup nodebrew`... Disable this behaviour by setting HOMEBREW_NO_INSTALL_CLEANUP. Hide these hints with HOMEBREW_NO_ENV_HINTS (see `man brew`). パスを通せと書かれているので、~/.zshrcに以下を追記 # nodebrew export PATH=$HOME/.nodebrew/current/bin:$PATH 設定を反映する source ~/.zshrc 今回はcdkも検証が完了しているv16.3.0を使うことにする % nodebrew install-binary v16.3.0 Fetching: https://nodejs.org/dist/v16.3.0/node-v16.3.0-darwin-arm64.tar.gz ######################################################################################################################################################################################################################### 100.0% Installed successfully % nodebrew ls v16.3.0 current: none % nodebrew use v16.3.0 use v16.3.0 % node -v v16.3.0 もう一度、cdkのバージョン確認コマンドを打鍵し、コーションが出ないか確認する。 % cdk --version 2.8.0 (build 8a5eb49) 問題なしなのでこれで完了

最近インフラ周りの勉強を始めたのでdocekr+laravelの環境をEC2上に実現したいと思い奮闘しています。 参考になった記事を貼っていきます。 記事 【AWS 入門】EC2とDockerでHello Worldしよう 【シンプル解説】docker-composeを使ってLaravel,nginx,MySQL環境構築する https://simablog.net/docker-laravel-nginx-mysql/ SSH接続後 phpをインストールする https://qiita.com/nagahama/items/2fdc820791bee5d564ca composer　install https://qiita.com/kawanet/items/30c1acd4bc90ee0e535d composer installの際のエラー(/usr/local/bin/docker-compose: line 1: Not: command not found) https://github.com/docker/compose/issues/6268 amazon linux内でcomposerのpathを通す(どこでもcomposerコマンドを使えるようにする) https://qiita.com/miriwo/items/b25f9d4d74b7103f6ff6

前書き Cloud Watchなどにも直接いけます。 Kinesis Data Firehose？？いやいやワイは直接S3にログをぶちこみたいんや！！ってお方向け。 WebACLのリソースは作成済みのテイで進めます。 やり方 ◾️ おおまかな流れ ログ保管用バケットつくる ロギング構成用リソースを定義 ロギングとバケットを紐付け ロギングフィルターを定義 ◾️ 実・践 適当なバケットを作りましょう。 （※バケットポリシーはWAFのロギング時に自動でアタッチされるっぽいのでこちら用意しなくても良いっぽいです。細かい挙動はちょっとよくワカラナイ。。） 注意点として、bucket名は aws-waf-logs-のprefixで始まる必要があるらしいです。 https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/logging-s3.html s3.tf resource "aws_s3_bucket" "b" { bucket = "aws-waf-logs-hogehoge" acl = "private" tags = { Name = "My bucket" Environment = "Dev" } } 次にロギング構成用のリソースを定義します。 waf.tf resource "aws_wafv2_web_acl_logging_configuration" "example" { log_destination_configs = [aws_s3_bucket.b.arn] resource_arn = aws_wafv2_web_acl.example.arn // ここは作成済みのweb aclリソースを指定するのじゃ } リソースタイプながいっすね笑 これでひとまず、WebACLで定義したルールにマッチしたリクエストのログが流れていくと思います。 次にロギングフィルターです。 ロギングフィルターではどのアクセスのログを取るか捨てるかを精査できます。 ちなみにロギングに関してはWAFの追加コストはかからないらしいので、S3の保存料金が上乗せされていく感じみたいです。まあでも少しでもコスト削減できますし、不要なログが増えるの邪魔なんでフィルターしたらいいんじゃないかなと思います。 https://aws.amazon.com/jp/about-aws/whats-new/2021/12/awf-waf-cloudwatch-log-s3-bucket/ 先ほどのwaf.tfに追記しましょう。 resource "aws_wafv2_web_acl_logging_configuration" "example" { log_destination_configs = [aws_s3_bucket.b.arn] resource_arn = aws_wafv2_web_acl.example.arn // 追加 logging_filter { default_behavior = "KEEP" filter { behavior = "DROP" condition { action_condition { action = "ALLOW" } } requirement = "MEETS_ANY" } } } logging_filterブロックで、ログのフィルターを定義しています。 filterがログに適用するフィルター、conditionが条件です。 conditionで指定した条件にマッチしたものがbehaviorで定義されているDROPの挙動になります。（DROPなので、つまりログを保存しないという記述になります。） また、action_conditionでactionをALLOWとしているので、WebACLで定義したルールのactionがallowのものが捨てられる対象となります。（例えばip制限のルール定義などを行なった場合などはallowを使ったりすると思いますが、その場合許可されたipからのリクエストのログを切り捨てるということになります。） ちなみに、default_behaviorでデフォルトの挙動（KEEPなのでログを送信する）を定義しています。 あとはrequirementなのですが、これは「または」や「かつ」のような使い方に似ています。 正確には、requirementがMEETS_ALLの場合は全てのconditionに一致した場合のみフィルターが発動します。逆にMEETS_ANYの場合はどれか一つのconditionに一致すれば発動します。 なので、もうお分かりかと思いますが、conditionは一つのfilter内に複数書くことができます。 例） resource "aws_wafv2_web_acl_logging_configuration" "example" { log_destination_configs = [aws_s3_bucket.b.arn] resource_arn = aws_wafv2_web_acl.example.arn logging_filter { default_behavior = "KEEP" filter { behavior = "DROP" condition { action_condition { action = "ALLOW" } } // 追加 condition { label_name_condition { label_name = "awswaf:111122223333:rulegroup:testRules:LabelNameZ" // ルールのラベルで条件を指定することもできる } } requirement = "MEETS_ANY" } } } 他にも様々な組み立て方でロギングフィルターのパターンが作れるのでぜひ試してみてください。 少し中途半端ですが今回は以上です！（眠くなったので！笑）

概要 ローカルPCからWSLでAWS上にRay clusterを作成し、ポートフォワーディングでローカルPC上でRay Dashboardが見られるようにする。 環境 Windows10 Home WSL Ubuntuディストリビューションをインストール済み Python3、pip3、Ray、botoをインストール済み ローカルPCの~/.awsディレクトリ配下のcredentialsにAccess key ID、Secret access keyを入力済み 踏み台用EC2を作成済み（EC2はUbuntu） 踏み台用EC2に割当てているセキュリティグループでSSHおよび8265番ポートを許可 手順 WSL Ubuntuを開き、下記コマンドを実行。 # 踏み台用EC2にSSH接続 $ ssh -i <踏み台サーバのpemファイル> ubuntu@<踏み台サーバのパブリックIP> # 以下は踏み台用EC2で実行 # Ray cluster作成 $ ray up -n example-cluster --no-config-cache RayClusterConfig2.yaml # Dashboard用のデフォルトポート8265番を踏み台用EC2の8265番ポートにフォワーディング $ ray dashboard -p 8265 --remote-port 8265 RayClusterConfig2.yaml 別のWSL Ubuntuを開き、下記コマンドを実行。 # EC2の8265番ポートをローカルPCの8265番ポートにフォワーディング $ ssh -i <踏み台サーバのpemファイル> ubuntu@<踏み台サーバのパブリックIP> -L 8265:localhost:8265 この状態でローカルPCのブラウザでhttp://localhost:8265/へアクセスするとRay dashboardが表示される。