はじめに 合格しました というわけで合格体験記です。こういうの一度書いてみたかったんだ とはいえ勉強法に関する良質な記事はすでにたくさんありますし、私自身も「実務経験＋参考書＋問題集」という王道ド真ん中を通ってきたため、新しそうなことを書ける感じはしません。困った で、少し違った視点から何か役立ちそうなトピックがないかと考えまして、今回は、 「Well-Architectedも一緒に勉強するといいってみんな言うけど、実際どの部分がどんな感じで試験に役に立つの？」 「そもそもWell-Architectedって何？」 という観点からまとめてみたいと思います。 Well-Architected Frameworkとは AWS公式が提供する、AWSを利用する上でのベストプラクティス集です。 「これに則って実装すればOK！」というものではなく、あくまでも「作ったものはベストプラクティスに沿っているか」「沿っていない時は、なぜ沿っていないのか（意図的なのか、考慮漏れなのか）」を検討するための指針となります。 どう役に立ったのか AWS SAA（ソリューションアーキテクト - アソシエイト）試験では、Well-Architected Frameworkの「5つの柱」にもとに問題が出題されています。 AWS 認定ソリューションアーキテクト – アソシエイトの認定では、顧客要件に合わせて AWS の Well-Architected ソリューションを設計およびデプロイする際に必要となる能力を備えていることを確認します。 また、SAA-C02の試験ガイドにおいても、テスト分野として5つの柱（から運用上の優秀性の柱を除いたもの）をベースにしたテスト分野が紹介されています。 つまり、AWS SAAを参考書等で勉強をすることでWell-Architectedに沿ったシステム構築ができるようになり、一方でWell-Architectedを理解することで、AWS SAAの出題に対して「なぜその選択肢がベストプラクティスなのか」という観点で解答できるようになる、という相互の関係があるということができます。 ここでは例として、「テスト環境を作りたい」というシチェーションへの対応を考えてみます。 これに関連するWell-Architected Frameworkの項目は以下のページです。 コードとしてインフラストラクチャを使用したり、構成管理システムを使用したりして本番環境に存在するコントロールに準拠して設定された環境をデプロイし、システムがデプロイ時に予想どおりに動作することを確認します。 「複数の環境を使用する」の項では、本番に近い環境をIaC（Infrastructure as Code）で作成してテストすることが推奨されており、あわせて運用上のポイントやメリットについても説明されています。また、この項の関連項目としてCloudFormationが紹介されています。 もちろん参考書や問題集を何周かすれば難なく答えにたどり着けるような例ではありますが、 参考書：CloudFormationの機能がわかる 問題集：CloudFormationを使うシチュエーションがわかる Well-A：ベストプラクティスとしてCloudFormationを使うべき理由がわかる の3点セットで覚えられるとよく定着しますし、試験中に思い出すためのきっかけにもなりますし、何より確信をもって解答できるようになるため、大変胃にやさしい自信につながります。ここが一番の役立ちポイントだったかと思います。 Well-Architectedの5つの柱と試験分野 ここからはWell-Architected Frameworkと試験分野について、関連するAWSサービスを抜粋しながら紹介していきます。 私なりの解釈で噛み砕いた内容のため、一部ざっくりしすぎて不正確な点があるかもしれません。予めご了承ください。 運用上の優秀性の柱 組織の構築などマネジメント側の話も多い柱ですが、アーキテクトの観点から身も蓋もない表現をするならば「いかに運用をラクにするか」という話がこの柱の主な話題になるかと思います。 手間を省いたり、障害を防止したり、安全にテストをしたりするにはどうするのがよいのか、という分野になります。 Well-Architectedの「設計原則」から引用すると"運用をコードとして実行する"、すなわちCloudFormationやOpsWorksなどのIaCなどがこの柱のポイントとして挙げられています。 また、Elastic Beanstalkなどを使用して環境構築の手間を省いたりする話もこのカテゴリに含まれています。 デプロイ管理システムを使用して変更を追跡および実装します。これにより、手動プロセスによって発生するエラーと、変更をデプロイする労力が減ります。 「労力が減ります。」いい言葉ですね。労力が減ることで仕事をしなくて済むより価値のある作業に人的リソースを割り当てられるというような表現は、AWSの資料では頻繁に見かけるイメージがあります。 そのほか、障害検知（Well-Architectedでは「ワークロードの正常性の把握」といったりする）の観点で、CloudWatchやCloudTrailなども関連サービスとして名前が出てきます。 ちゃんとログを取り、ちゃんと障害検知を仕掛けておけば、のちのち何か起きたときに面倒なことにならなくて済むと考えれば、これも一種の労力の削減でしょうか。 なお、運用上の優秀性の柱に関してはSAA-C02のテスト分野に対応するカテゴリが無いので、配点上はどこか別の分野に吸収されているものと思われます。さよなら…… セキュリティの柱 / セキュアなアプリケーションとアーキテクチャの設計 「セキュリティ要件への準拠」「ストレージと転送データの暗号化」「リソースの権限管理」といった内容の柱です。 非常に範囲が広く勉強が大変な分野ですが、幸いWell-Architectedの上記ページではプラクティスごとに関連項目としてサービスが紹介されていますし、内容も一問一答といった粒度のためいくらか飲み込みやすくなっています。 それでもセキュリティのためのサービスとしてWAF, GuardDuty, ACM, KMS, Shield, IAMなどを押さえたうえで、セキュリティ関連の設定についてS3, RDS, EBS, ALB, VPC, CloudFrontなどなどへの個別への対応も考えないといけない分野ではありますので、それはそれはもう巨大な知識領域になります。 そりゃ個別にAWS Certified Security - Specialtyの試験ができますわな…… あとは実際の構成例として「適切なユーザーにのみデータを配信する方法」などもこのカテゴリに入るかと思います。 例えばいにしえの呪文「直リン禁止です！」は、WAFでリファラ制限をかけて画像リンクを外部から利用できないようにするといった方法で対応可能です。例えが古すぎますかね？ ともかく繰り返しになりますが、範囲が広く、それでいて実践的な分野ですので、Well-Architectedと参考書の合わせ技でしっかり習得できればAWSの活用の幅がかなり広がってくるかと思います。 信頼性の柱 / レジリエントアーキテクチャの設計 「可用性」「フェイルオーバー」などがキーワードになる柱です。早い話が分散させたりスケールさせたりしましょうね、という内容です。 分散やスケールというと、Route 53のフェイルオーバールーティングやELBとAuto Scalingの組み合わせ、RDSのマルチAZ構成にAurora Serverlessなどが思い浮かぶところですが、Well-Architected FrameworkではSQSが頻繁に登場してくる印象があります。 「データが壊れる」「サーバーが落ちる」以上に、「メッセージ（処理の命令）が失われる」というトラブルは頻発します。「SNSからLambdaに連係したがLambdaが3連続でエラーを吐いた」とか、「DynamoDBのキャパシティに引っかかって書き込みがコケた」とか、「たまたまプライマリが落ちてセカンダリへ切り替えているタイミングだった」とか、「スケールが間に合わなかった」とか、とにかくあちこちでメッセージはロストします。 そんなときでも、メッセージを一度SQSに入れておくことで、処理に失敗したメッセージをキューに保持して再試行したり、後続処理だけスケールして性能低下を防いだりといった手段で信頼性を高められる、というメリットがあります。 さすが最古のAWSサービスとでもいうべきか、ベストプラクティスな設計の中心にはしばしばSQSが存在しているようです。 また、「壊れる前に検知する」「壊れたときに復旧しやすくする」という観点で、CloudWatchやX-Rayなどの利用もこの柱では推奨されています。 パフォーマンス効率の柱 / 高パフォーマンスアーキテクチャの設計 「レイテンシー」「オートスケーリング」「キャッシュ」あたりがこの柱のキーワードです。必要な性能を実現するために、適切なサービスを必要な分だけ使いましょうというテーマです。 このあたりはセキュリティの柱と同じく、Well-Architected Frameworkでサービス名を挙げながら細かく触れられている部分ですので、「試験対策としてのWell-Architected」の効果が高い部分ではないか思います。 （そして、セキュリティの柱と同じく範囲がデカいです。） ところで、パフォーマンスとコストのバランスをどう取っていくかという点は実際の設計でもしばしば話題に上がるところです。費用を安く抑えるためのはポイント次の「コスト最適化の柱」で触れられますが、一方で小規模な開発ではなかなか出番のないような高額で高性能なサービス（ElastiCacheやDynamoDB Acceleratorなど）の出番を学べるのがこの「パフォーマンス効率の柱」でもあります。 コスト最適化の柱 / コスト最適化アーキテクチャの設計 お安くAWSを使うためのノウハウが詰まった柱です。みんな大好きコスト最適化。 Well-Architected Frameworkでは「使う分だけ払う」「使う量が分かっている時は先払いで割引を受ける」という観点で、（主にEC2の）オートスケーリングとキャパシティー予約について触れられています。そのほか、Organizationの一括請求や、マネージドサービスの活用による「人的コスト」の削減などもこの柱の話題です。 このあたりの話は、他の柱と内容が重複している部分も多いのかなというように感じます。 人的コストの削減は「運用上の優秀性の柱」と近いものがありますし、EC2のオートスケーリングは「信頼性の柱」「パフォーマンス効率の柱」でも触れられている内容です。 あるAWSサービスに対して複数の観点からメリットや意義を説明できるようになる（例：Auto Scalingについて「可用性」「パフォーマンス」「コスト」の観点で説明できるようになる）という点は、Well-Architectedが試験準備に役立つ大きなポイントかと思います。 また、1つの「やりたいこと」に対して複数のアーキテクチャを比較検討するという観点もコスト最適化やパフォーマンス効率での重要なポイントです。 RDSの性能が足りていないとひとくちで言っても、解決策として垂直スケーリングする、リードレプリカを配置する、Auroraに移行する、ElastiCacheを導入するなどさまざまな方法を取ることができます。 その中から「要件（コスト・性能・耐久性など）に合わせて検討し、適切な方法を選びましょう」というのがWell-Architectedの重要なテーマであり、そして試験で問われる部分でもあります。 おわりに というわけで、Well-Architected Frameworkを読んでおくと、 AWSのベストプラクティスを踏まえた設計が分かる ユースケースごとに関連するサービスが分かる というメリットがあるよというお話でした。 受験者行動規範があるため出題内容には触れられませんでしたが、試験対策としてはWell-Architectedを知っておくと「設問の意図が分かる」「解答の手がかりが増える」「シチュエーションとサービスが紐づく」というメリットがあるという点をお伝えできていれば……と思います。 もちろん最速合格とは程遠い、ある意味で試験対策としては回り道な方法ではありますが、実際に仕事などでAWSを使っていく上でWell-Architectedの考え方は非常に役に立つ内容になっています。 「資格取得を急がず、かつ取得がゴールではない方」「今後もAWSを実務で使っていく方」「少しでも試験に自信と安心感を持って臨みたい方」は、ぜひ参考書等と合わせてWell-Architected Frameworkに目を通してみてはいかがでしょうか。 余談1: どれくらい時間かかった？ この手のエントリだと取得までの時間がついてるのが一般的ですよね！（偏った知見） ただ私の場合相当遅めで、4月にクラウドプラクティショナーを取得してから8月までと考えると実質3～4か月くらいかけたことになります。 とはいえ勉強自体も本腰入れてガッツリ取り組んだというよりは、ヒマなときに参考書をつまみ読みして……というくらいの熱量でのんびり進めていましたので、トータルの「勉強時間」としては30～50時間くらいに収まるかと思います。 ほら、少し期間をあけて反復学習したほうが覚えやすいってエビングハウスさんも言っていますし…… 余談2: 資格取得して実務で役立ってる？ バッチリです。1つ例をご紹介します。 先日マネジメントコンソールでEC2関連の作業を行っている際、io1タイプのEBSボリュームがなぜかポツンと1つだけあることに気づきました。試験の参考書知識で「io1は結構高い」と分かっていたので確認してみたところ、「しばらく前に作ったボリュームで、DB処理のために不定期に1,000IOPSくらいの性能が必要になる。容量が小さいのでgp2だとバーストを使い切ってしまう。」ということでこの設定になっている模様でした。 これを「データベースをEC2でホストしています。ストレージには1,000 IOPS程度の性能が必要です。この要求を満たすコスト最適なストレージタイプは何ですか。」というような問題だと考えるならば……現時点での答えはgp3です。IOPSはベースラインで3,000もありますし、なによりio1よりずっと低コストです。 スループットもベースラインで足りそうでしたが、もしもっと必要だとしてもなおio1よりは安くなる計算でした。ということでボリュームタイプを変更し、これだけで月70ドル以上のコスト削減を実現することができました。 ……とこんな感じで、試験勉強もなかなか活きてくるなぁと感じている今日この頃です。普段EC2はあまり触らないほうですので、この辺りは受験勉強しなければ気づけなかった部分かなと思います。 自分が普段あまりやらない範囲のサービスを勉強するきっかけとして、SAA試験の受験はなかなか役に立っているなと感じています。 ソリューションアーキテクト試験、おすすめです。皆様もぜひいかがでしょうか。

初めに 今回はリージョンとアベイラリティゾーン（AZ)について学びました。 なんで設定するのかわかってなかったのですが、 「可用性」を高めることができる　ということがわかりました。 リージョンとは リージョン＝領域 リージョンとリージョンは完全に別れているので、 あるリージョンで障害が発生しても他のリージョンには影響がありません。 ↓ 障害が発生した時、リージョンを切り替えるようにすれば、 「可用性」が上がります！ リージョンはどこでも良いのか 応答時間を早くしたいなら... 日本でサービスを展開する場合、リージョンは日本にした方がサーバーの 応答時間は早くなるそうです！ 最新サービスをいち早く利用したいなら... まずはアメリカのリージョンからサービス提供が始まり、 徐々に他に広まっていくという感じのようで、リージョン限定サービスがあるようです。 アベイラビリティゾーンとは １つのリージョンは複数のアベイラリティゾーンから構成されています。 リージョンとは違い、互いに接続しています。 アジアパシフィック（東京）は、"ap-northeast-1a"、"ap-northeast-1c"、"ap-northeast-1d" の3つのアベイラビリティーゾーンから構成されています。 「お皿がリージョンで、スパイスがAZ」 というイメージです。 どのリージョンにもAZは２つ以上存在しますが、 何故かというと　やはり可用性です。 １個がダメになっても、他で動かせるようにしています。 終わりに 前回のセキュリティ対策についてもそうですが、 AWSって色々なことを考えて作られてるんだな...と思いました。 「なんでこんなのやるんだろう・・・」っていうものにも、ちゃんと意味があるんですね。 ちなみに前回の記事 参考になるサイト

初めに 今回はリージョンとアベイラリティゾーン（AZ)について学びました。 なんで設定するのかわかってなかったのですが、 「可用性」を高めることができる　ということがわかりました。 リージョンとは リージョン＝領域 リージョンとリージョンは完全に別れているので、 あるリージョンで障害が発生しても他のリージョンには影響がありません。 ↓ 障害が発生した時、リージョンを切り替えるようにすれば、 「可用性」が上がります！ リージョンはどこでも良いのか 応答時間を早くしたいなら... 日本でサービスを展開する場合、リージョンは日本にした方がサーバーの 応答時間は早くなるそうです！ 最新サービスをいち早く利用したいなら... まずはアメリカのリージョンからサービス提供が始まり、 徐々に他に広まっていくという感じのようで、リージョン限定サービスがあるようです。 アベイラビリティゾーンとは １つのリージョンは複数のアベイラリティゾーンから構成されています。 リージョンとは違い、互いに接続しています。 アジアパシフィック（東京）は、"ap-northeast-1a"、"ap-northeast-1c"、"ap-northeast-1d" の3つのアベイラビリティーゾーンから構成されています。 「お皿がリージョンで、スパイスがAZ」 というイメージです。 どのリージョンにもAZは２つ以上存在しますが、 何故かというと　やはり可用性です。 １個がダメになっても、他で動かせるようにしています。 冗長化:システムの稼働を止めない このように複数のAZにサーバーを設置しておき、 待機状態にしておけば、障害が発生してもすぐに切り替えることができます。 障害が起こっても稼働を継続できるように 予備を準備しておくことを、 「冗長化」といいます。 終わりに 前回のセキュリティ対策についてもそうですが、 AWSって色々なことを考えて作られてるんだな...と思いました。 「なんでこんなのやるんだろう・・・」っていうものにも、ちゃんと意味があるんですね。 ちなみに前回の記事 参考になるサイト

はじめに こんにちは、未経験からエンジニア転職を目指している27歳です。 エンジニア転職を目指す際、ふと「未経験とプロのエンジニアの違いってなんだ？」と思ったことはないでしょうか？私もそのうちの1人です。もちろん明らかに違うこと自体はわかっているのですが具体的に言語化ができていませんでした。 なるべく入社前後のギャップを埋めたいと感じていた当時の私は実務を体験をすることによってそのギャップを少しでも埋めることができ、入社後の成長スピードを高めることが出来るのではないかと考えていました。 そんなある日、ご縁があり実務を体験させていただく機会がありましたので、実務をする中で感じたこと、思ったこと、実際の実務内容を体験記として書き記しておきたいと思います。 同じような疑問を抱いている方の少しでも参考になれたら幸いです。 9/26日追記 実務内容詳細興味ないよって人は最後ら辺だけ読むのが良いかもしれません笑 こんな人に読んで欲しい ・未経験からエンジニアを目指している方 ・実務案件って実際どんな事やるの？と疑問に思っている方 ・実務と未経験のポートフォリオとの違いってなんなの？と思っている方 ・企業のデータ分析ってどうやってやってるの？と疑問に思っている方 案件の経緯 今回の実務案件はクライアントが運用している自社サービスのモニタリング体制が現状構築できておらず、気軽にデータ分析ができていないためデータ分析体制を構築してほしいとの事。 クライアントから与えられた情報は以下 案件内容 データのモニタリング体制を整える 実装期間：1ヶ月半 課題 データを気軽にモニタリングできない 定期的なモニタリングができていない 現状のモニタリング体制図 EC2を踏み台サーバーとしてしてMySQLにログインし、MySQL内でSQLコマンドを打ってデータ分析をしている状況。EC2へSSH接続をしてからMySQLへ段階を踏んでログインする必要があるため手軽にモニタリングができない。また、ユーザーに関わる情報を数値化して定期的にモニタリングすることができていない。 最終的な構成 インフラ構成図 説明は後ほど 要件定義 このような課題を解決するためにまずはクライアントと要件定義(要求を考慮し、システムとして必要な要件をまとめること)のすり合わせを行なった。 その前に要求分析(相手の要望を抽出し分析すること)を行なったが今回は割愛する。 要件定義は以下のようになった。 要件定義：機能要件 データベースに直接アクセスできる SQLを自由に叩ける モニタリング指標の各項目が数字として表示される モニタリング指標の各項目がグラフ化して見ることができる モニタリング指標の各項目を自由に変更できる ユーザー管理機能（アクセス権限の設定） 要件定義：非機能要件 個人情報は閲覧できない 読み込み専用にする 本番DBに負荷がかからない インターフェイスはデザイン崩れしない 画面は3秒以内に表示できるようにする 指定されたユーザーのみ、ユーザー管理を自由に行えるようにする 死活監視：モニタリングサービスが落ちたら検知できる エラー監視：エラーが発生したら検知できる これらを満たすソリューションを考え構築することになった。 また、運用コスト上限は5000円/月と指定された。 ガントチャート作成 実装に入る前にタスクを洗い出し、ガントチャートを作成した。 一部抜粋 意識したこと ・タスクの細分化 いかにタスクをばらすことが出来るかを意識し作成。 実務を進めていく中でタスクが増えたり、タスクを更に細分化出来ることがあるので 都度修正することに努めた結果、最終的にタスク数が92個となった。 ・バッファを意識した作成 実務では想定外の詰まりが多々あると予想していたので各実装フェーズ毎にバッファを2日間設けるようにした。これにより実装が詰まって進捗が遅れても修正できるように設計している。 実装フェーズ 要件定義実装準備が完了したらいよいよ実装フェーズに突入。 実装で大変だった事 本番DBへ負荷がかからないことを考慮した上で個人情報流出を防ぐためにマスキング処理をどうやって行うのか。 データを取ってきてマスキングし、可視化するまでの一連の流れをどう定期的に自動化するか これらの対策は後半に記述。 1〜2週目 技術選定、初期実装フェーズ 技術選定 そもそもどうやってモニタリング体制を整えたら良いのかわけわかめ状態。 自分で作成するのか元からあるツールを使用するのか。 自身で調べたり、知り合いのエンジニアに通常企業ではどのようにデータのモニタリング体制を構築するかヒアリングをしたところBIツールなるものを使うのが良さそうとの結論に至った。 BIツールもなにそれ美味しいの状態だったので調べた結果を書き留めておきたいと思う。 BIツール 「BIツール」とは、「ビジネス・インテリジェンスツール」のことで、企業が持つさまざまなデータを分析・見える化し、ビジネスの意思決定に役立てるデータ分析ツールの事。 まあ言ってしまえばデータ分析に特化したWEBアプリケーションサイトのような物。 BIツールは有料から無料の物までさまざまあり、備わっている機能も変わってくる。 BIツール検討比較表 今回は以下の観点で比較検討を行なった。 比較観点 料金コスト(全体コストが5000円なので2000円以内が望ましい) 直感操作(外部委託予定であるため直感操作性も重視する必要がある) 保守、運用(オンプレミス型のBIツールだと保守、運用が必要になるのでクラウドBIが望ましい) 比較の結果今回AWS QuickSightを選定することにした。 他ツールの不採用理由は以下 Tabeau →予算オーバー Power BI →Mac対応不可 Re:dash →データ分析を行う為にはSQL文しか使用できず、GUIで直感的な操作ができない為 Metabase →オンプレミス(自社構築、運用が必要)のため、環境構築、サーバー運用が必要なので不採用。 AWS QuickSight特徴 ここで上記での優位性以外にもAWS QuickSightを採用したメリットがあるので記述していきたいと思う。 1. 多彩なグラフ作成、ドラック&ドロップでの直感操作 Amazon QuickSight Gallery https://aws.amazon.com/jp/quicksight/gallery/ より 可視化できるグラフの種類が豊富かつSQL文に不慣れな方でもGUI操作で容易にグラフを作成できる。クライアントの意向で今後データの分析のみ外部委託を行う予定でかつそこまでエンジニア歴が長くない方が担当する可能性もあるとの事だったので操作性に関しては考慮している。 2. MLインサイト機能 DevelopersIO https://dev.classmethod.jp/articles/amazon-quicksight-announces-general-availability-of-ml-insights/ より MLインサイトは機械学習を活用した機能となっており主に以下の機能がある データのトレンド予測を行ってくれるので今後の推移が予想できる 異常値を検出してくれるのでサイト運用上の問題点を洗い出しできる 3. 多様なデータソースに対応 AWSサービスなだけあってRDS、S3、Athena等AWSの様々なデータソースにアクセス可能 今回データソースがRDSなので接続が容易にでき、クライアント側の構築の手間を減らすことができる。 初期実装 まずはBIツールの操作性を確認するため本番サービスのRDSからDumpデータ(データを他のDBへ移行するためのデータ)を取ってきて構築したRDS(MySQL)に流し込み本番環境に見立てたRDSを構築。BIツールとRDSを直接連携し本番データの可視化を行なった。 初期実装構成図 本番データ可視化 本番データの可視化はできている模様。 機能要件であるモニタリング指標の数値化、グラフ化、項目を自由に変更できる、アクセス権限周り等要件を満たしていることが確認できた。ここまでの流れとしては悪くなかったと思う。 あとはマスキング処理を施せば大枠は完成と思っていたのだが、、、。 問題はここから。 3〜4週目 マスキング処理 今後データ分析は外部委託を検討しており、個人情報流出を防ぐため事前にマスキング処理を施したデータを分析できるようにしてほしいというのが今回の重要なポイントの一つ。 そこで次のような構成でマスキングを行う事にした。 ①本番DBのスナップショットからマスキング用のRDSを作成 ②マスキング処理を施した後Dumpデータ(データを他のDBへ移行するためのデータ)を抽出 ③予め作成しておいたデータ分析用のRDSへDumpデータを流し込み復元 ④Dumpデータを取り終わったマスキング用RDSは都度削除する事によってデータ分析者の個人情報閲覧を防ぐ この一連の流れをEC2上でシェルスクリプトを作成 シェルスクリプトファイルをcronにより定期実行設定を構築した。 ここまで構築した上で一度クライアントにレビューをいただける機会を設けていただいた。 そこである問題に直面することに。 「これってSQLクエリ打つ時毎回パスワードとか入れなきゃいけないんですか？」 確かに言われてみればQuickSightからRDSへ接続しSQL文を打つ際に毎回ユーザー名とパスワードを入れなければならない。これがSQLクエリを気軽かつ自由に叩きたいクライアント側としては非常にネックな部分であった。 5〜6週目 構成図再構築、怒涛の追い込み 最終的に課題になっていたのは SQL文を気軽かつ自由に打てる環境を整えることであった。 課題を考慮した結果、AWS Athenaを採用することにした。 それに伴いAthenaを介すことでQuickSightでデータを可視化することが出来るので、わざわざコストが嵩む分析用のRDSを建てる必要も無いと感じ、S3にマスキングデータを蓄積するよう変更した。 上記を考慮し最終的に冒頭にも記載したインフラ構成図に落ち着いた。 ・本番DBからデータを取ってきてマスキングし、可視化するまでの一連の流れ ①MasterDBの自動スナップショットからマスキング用RDSの作成 ②マスキングRDSにマスキング処理、 ③スナップショットを取得 ④取得したスナップショットをS3にエクスポート ⑤S3データをGLue Crawlerを使用しデータ整形化しDataCatalogにメタデータとして保存 ⑥Athenaでクエリ実行、クエリ結果テーブル作成 ⑦QuickSightにて可視化 クエリを打たずに単純な可視化であれば、Athenaを介さずDataCatalogをQuickSight直接参照できる。 ・一連の流れを自動化する方法 ①〜④まではcronにて定期実行 ⑤はCrawlerの定期実行処理設定にて定期実行 ⑦は一度作成したデータの更新処理設定をQuickSight内で設定可能。定期的に同じデータ分析を確認したい場合、日時で最新のデータに更新して閲覧することが可能。 ※この一連の流れとそれを自動化する方法の詳細はかなり長くなりそうなので後日別記事にて記載したいと思う ここでGlueと言うAWSの新しいサービスが出てくる。 自分自身も初めて使用するサービスなのでAWS Glueの概要をまとめていきたいと思う。 AWS Glueってなんぞ？ AWS Glueはデータの抽出や変換、ロードを簡単に行える完全マネージド型サービスのこと。サーバーレスのため自分自身で管理、運用する事必要がない。 様々なGlueの機能の中で今回使用した機能は次の2つ。 Glue Crawler データ抽出GlueのDataCatalogにメタデータを作成するプログラムのこと。 DataCatalog メタデータを管理するリポジトリ機能のこと。GlueCrawlerを使用しDataCatalogを作成する事によってデータを分析しやすいように整形。 データカタログはメタデータ（データのスキーマ情報（データのカラム名やデータ型））を保持しており、データそのものはデータ元に残っている。あくまでもデータの情報のみ保持しているという感じ。 よってデータ自体がDataCatalogあるように見えるが、データ本体はS3にあるのでS3のデータを削除すると当然Athenaで参照できていたDataCatalogデータも見る事ができなくなる。 使い方としてはAthenaで分析する際にS3からデータを持ってくる。AthenaとS3で直接連携しデータ分析することもできるが、その際にS3にあるデータがどのようなデータであるのかが分からないのでカラム名やデータ型などを一つ一つAthena指定していく必要があり、かなり手間が増える。 そこでGlue Crawlerで分析してカタログを作成する事によりテーブルを自動整形しデータ分析をできる状態にしてくれるのである。DataCatalogはCrawlerで解析したメタデータを管理すると言うイメージ。 最終提出 想定外の詰まりが多々あったがなんとか納品することができた。 Athenaクエリ結果例 うん、マスキング処理、SQLクエリを実行できている クライアント側から提示いただいた3つのSQL文を実行し、クエリ実行時間を計測。 結果はクライアント側の許容範囲内で了承をいただいた。 データの可視化 Athenaのクエリ結果も無事可視化できました。 マスキング処理も問題なく反映されています。 一回データセットを作成してしまえばQuickSightに自動保存され定期的(今回は日時)に同じデータ分析を最新の更新データで閲覧することが可能。なんて便利なんでしょう。 概算運用コスト 続いて概算の月額コストを記載 サービス名 月額料金 説明 AWS QuickSight 18$ GCP Cloud SQL(HDD) RDS 1.8$ マスキング用RDS、一日2時間稼働 RDS 7.2$ RDS S3エクスポート料金 一回辺り0.012/GB×20GB EC2 1.87$ cron定期実行処理用EC2、一日3時間稼働計算 Glue 1.87$ Crawler処理一回辺り、0.88/1hour÷6(1回の起動時間10分) 合計 33.27$ 5000円/月という予算上限額を超えずに済んだ。 体験して分かった未経験が作る制作物と実務案件との違い もちろんコードの記述量等目に見える物は天と地ほどの差があると思うが今回は考え方の違いにフォーカスして感じたことを記載していきたいと思う。 当たり前のことかもしれないがこれって本当に実運用を考えて作成できているか？と言う視点を極限まで考える必要が実務にはあると改めて感じることができた。 ユーザーの操作性、サーバーが落ちた時の対応、アップデート方法、データ蓄積に対してスケールアウト対応を考慮できている構造になっているか、テスト自動化、セキュリティ等言い出したらキリが無い。 こういった今だけでなく数年先まで見据えた運用ができるようなソリューションを考え提案し、納品できるかが実務案件には求められる。 また自分で作る制作物とは違い納期、いわゆる納品のデットラインは必ずと言っていいほどある。納期は何がなんでも最優先。 納期に間に合わせる範囲でのベストなソリューションを考える必要がある。 ソリューションのクオリティと納期のバランスを考えるのが非常に難しかった。 実務において感じたこと 実務を通じて今後役に立ちそうだなと感じたことを追記したいと思います。 ①この課題解決に「そもそもコード書く必要ある？」と実装前に疑ってかかる 最初この案件を聞いた時、自分でデータ分析サイトを作成するのかななんて思ってました。 もちろん可能性としては出来るかとは思います。 ですが今回の納期までの期間の短さ、また運用コスト、要件を満たしているツールが既にあるのであればわざわざコードを書いて作らずそれを使用するべきなんですよね。 未経験だとなんでも自分自身で作り上げたいみたいな考えに陥りがちなのでその考えを改めて持つことができたのは良かったと思います。 ②デメリットに目を向ける ソリューションを考える際に、メリットにばかり目がいきがちであると痛感しました。 これでやりたい実装ができる！！と思うとすぐにそのソリューションを採用したくなってしまいます。 そのせいでデメリットをあまり考慮しないが上に実装を進めていく中で要件を満たせない状態に陥り、ソリューションを再考しなければならなくなったことが何度もありました。 今後はソリューションを検討する際、デメリットファーストで考えていきたいと感じております。 あとがき 今回上流から下流工程までの一連の流れを未経験のうちに経験できたのは自分の中で非常に良い経験でした。 かといってプロのエンジニアとの差は実際にプロのエンジニアの方と関わった上でまだ歴然であると感じております。 しかし今回の経験は今後のエンジニア人生において直接でなくても確実に役に立つとも感じております。 この経験を糧に就職活動に臨みたいと思います。 最後までご覧いただき本当にありがとうございました！！ この記事が少しでも良かったと思っていただけましたらLGTMポチッとしていただけますと幸いです。

概要 Amazon Athenaのクエリーで json_extract 関数を利用する場面 ソースとなる情報はJSONのためjson_extract()関数を使用して目的の値を取得しようと考えました 一部JSONのキー値に . （ピリオド）を含むケースがありました 目的のキーはJSONPathで指示しますが、キー値をそのまま指示しても期待通りの動作をさせられず困りました その回避方法を記録します。ただし、条件付きであり、ベストな解決方法でないかもしれません json_extract 関数について 書式はおよそ下記のようになります json_extract(<入力JSON文字列>, <取得するJSONPath文字列>) 正確にはドキュメント 1 参照なのですが、JSONPath-like expression と記載があり、JSONPath風の記述、ということかと思います。 実施した内容 具体的に状況を示します 想定するソースjsonは下記のようにキー値に . を含みます キー値 key.name を指定し、your-name が取得できることが期待する動作です ソースとなるjson {"key.name": "your-name"} なにも考えずAthenaで実行したqueryと結果 SELECT json_extract('{"key.name": "your-name"}','$.key.name') AS key_name key_name ------ null 既に記述した通り、 $.key.name は、下記のような構造の場合のPathを示しますので、指示が間違っています {"key": {"name": "your-name"}} 念の為確認してみました。 SELECT json_extract('{"key": {"name": "your-name"}}','$.key.name') AS key_name key_name ------ "your-name" JSONPathを少し調べて試したqueryと結果 そもそも、JSONPath2について良く知らなかったので少し検索したところ、$.['key.name'] のような記述が適しているようです SELECT json_extract('{"key.name": "your-name"}','$.[''key.name'']') AS key_name INVALID_FUNCTION_ARGUMENT: Invalid JSON path: '$.['key.name']' エラーになってしまいました。JSONPathとして正しく解釈されないようです。 Athenaで利用しているJSONPath（のサブセット？）では実装されていないということかもしれません。 暫定対応（一応の解決） 入力JSON文字列のキーを書き換えてしまう方法です。 SELECT json_extract( replace('{"key.name": "your-name"}', '"key.name"', '"key_name"') /* "key.name" -> "key_name" と置換 */ ,'$.key_name') AS key_name /* JSONPathも key_nameとする */ key_name ------ "your-name" 同じキー値や、値部分にマッチしてしまった場合はすべて書き換えてしまうことになりますので、危険です。 入力値の仕様上問題なければ、という条件付きになりますが、一応の解決となりそうです。 https://docs.aws.amazon.com/ja_jp/athena/latest/ug/querying-JSON.html ↩ https://github.com/json-path/JsonPath ↩

Terraform の概要について調べてみる。 Terraform とは？ インフラの構成をコードで宣言できる、IaC(Infrastructure as Code)を実現するツール。 インフラ開発がシンプルかつ高速になる。 AWS, Azure, Google Cloud Platform などに対応。 .tf ファイルと　HCL (HashiCorp Configuration Language) により実装。 基本的なコマンド terraform の操作を行うための基本的なコマンド。 terraform init ワークスペースを初期化するコマンド、 terraform を実行するのに初期化は必須。 .tf で使用しているプラグインのダウンロードなども走る。 % terraform init Initializing modules... Initializing the backend... Successfully configured the backend "s3"! Terraform will automatically use this backend unless the backend configuration changes. Initializing provider plugins... ...... terraform plan コードを実行すると何が起こるか、リソースがどのように変更されるかを terraform が教えてくれる。 % terraform plan An execution plan has been generated and is shown below. Resource actions are indicated with the following symbols: ....... Plan: 1 to add, 0 to change, 0 to destroy. terraform apply 書いたコードを実際のインフラに適応する。 改めて plan の結果が表示された後、確認が表示される。 % terraform apply ...... Plan: 0 to add, 2 to change, 0 to destroy. Do you want to perform these actions? Terraform will perform the actions described above. Only 'yes' will be accepted to approve. Enter a value: yes ...... 構成要素 terraform　を構成する基本的なブロック。 resource EC2 インスタンスのようなリソースの定義を行う。 resource "aws_security_group" "ec2" { ...... } variable 変数を定義する。 以下の例ではデフォルト値を設定している、 terraform 実行時に上書きしない場合はこの値が使われる。 variable "region" { default = "ap-northeast-1" } locals ローカル変数を定義できる。 variable と異なりコマンド実行時に上書きできない変数。 locals { cf_zone_id = "cfzoneid" site_origin_id = "siteoriginid" } output 出力値を定義できる。 値は apply 時にターミナルで確認したり別のモジュールから取得したりできる。 output "region" { value = "${var.region}" } data 外部データを参照できる。 以下の例では　Amazon Linux 2 の AMI リストを参照している。 data "aws_ami" "recent_amazon_linux_2" { ...... } provider Terrraform は AWS 以外にも GCO, Azure などに対応しているがその違いを吸収するのがプロバイダ。 provider "aws" { region = "us-east-1" alias = "virginia" } 随時更新中です...... 参考資料

SpringBootで作っているアプリケーションを、SpringNativeでNative化しています。 Native化のハードルとして「ビルド時間が長い」ことが結構ストレスだったりします。 ローカルマシンだと、ビルドが30分近くかかったり、メモリ不足でビルド自体がエラーで落ちたりします。 AWSにビルドサーバー作ってビルド時間の短縮とかをしていたんですが、GitにPushしてビルドサーバーの方でPullしてというのがちょっと面倒。 GithubActionsでCIもしているが、どうにもこうにも遅かったり、メモリ不足でエラーになったりする。 その解決策として「Self-hosted runner」を使って強めのインスタンスでビルド時間の短縮を実現しました。 欲しい環境 ・SpringNativeでNative-Buildできる環境 ・Dockerが使える AWSで利用したUbuntuのAMI 時期によって更新されていくので日付の部分は探す際には、違う日付になっている場合があります。 ubuntu-focal-20.04-amd64-server-20210430 docker-ceインストール #docker-ce install sudo apt install -y apt-transport-https ca-certificates curl software-properties-common curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - sudo apt-key fingerprint 0EBFCD88 sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" sudo apt update sudo apt install -y docker-ce sudo systemctl enable docker sudo systemctl start docker docker実行時にsudoしなくていいように #No sudo for docker sudo gpasswd -a $USER docker ここで、設定反映のため一度ログアウトして再ログインする dockerの実行テスト #docker test docker run hello-world SpringNativeのビルド環境を作っていく 必要なライブラリ 以下のライブラリのインストールが必要でした。 #required lib sudo apt install -y zip sudo apt install -y gcc GraalのJava11を入れる sdkmanを使って入れていきます。 sdkmanについてはこちら https://sdkman.io/ #java11 graal curl -s "https://get.sdkman.io" | bash source "$HOME/.sdkman/bin/sdkman-init.sh" sdk install java 21.2.0.r11-grl sdk use java 21.2.0.r11-grl gu install native-image 自分は「maven」使っているのでインストール #maven sudo apt install -y maven Self-Hosted Runnerの設定 ここまで設定したら、GitHubActionsのSelf-hosted runnerとして使う設定をします。 Githubのリポジトリで「Setting > Actions > Runners」から「Add Runner」する。 「OS」と「Archtecture」は、利用したいインスタンスに合わせて設定する。 こんな感じで設定画面が出るので適宜設定する 設定完了したら実行 ターミナルを閉じても実行され続けるように、バックグランドで実行させる。 #self hosted runner. for background. cd ~/actions-runner nohup ./run.sh & 実行されているかプロセス確認 実行されていますね。 ps -a PID TTY TIME CMD 18425 pts/0 00:00:00 run.sh 18429 pts/0 00:00:00 Runner.Listener 18445 pts/0 00:00:00 ps sshを切って、githubから稼働状況を確認します。 動いてますね 終了させたい場合はkill kill <PID> 実際にCIを動かしてみます。 GithubActionsの使い方についてはここでは話しませんので、 公式のドキュメントなど見てみてください！ https://docs.github.com/ja/actions ビルド時間がどう変わったか GitHubの無料のRunnerの場合（ubuntu-20.04） 約19分（18分41秒） ローカルよりは早いけど、メモリが足りないときはどうしようもないです。 大きなプロジェクトになると、メモリエラーでビルド自体できなくなります。 Self-hosted runnerの場合（ubuntu-20.04 c5n.4xlarge 16vCpu/32GB） 約6分（5分51秒） 結構早くなりました！このくらいなら我慢できる。 もっとハイスペックなマシンを用意してスレッド設定をもっと増やしたら、もっと早くなるかも。 最後に 今回は、「Self-hosted runner」をEC2で作っています。 必要に合わせて起動したり停止したりする予定ですが、Fargateなどで必要な時だけ自動で起動、終わったら終了するようにするのもいいかもしれませんね。 時間ができたらやってみたいと思います。 余談 SpringNative化したRestAPI アプリケーションの起動時間は「0.134s」と爆速。 kubernetesでのPod起動も数秒になりました！ オートスケールやノード障害時の起動処理もめちゃくちゃ早くなって、提供サービスの可用性が高くなるのでよ良さそうです！ あと、「作業マシンのメモリを箱開けて増強したら？」と言われたんですが、会社のリースのマシンではそれは無理っすｗ

SpringBootで作っているRestAPIアプリケーションを、SpringNativeでNative化しています。 Native化のハードルとして「ビルド時間が長い」ことが結構ストレスだったりします。 ローカルマシンだと、ビルドが30分近くかかったり、メモリ不足でビルド自体がエラーで落ちたりします。 AWSにビルドサーバー作ってビルド時間の短縮とかをしていたんですが、GitにPushしてビルドサーバーの方でPullしてというのがちょっと面倒。 GithubActionsでCIもしているが、どうにもこうにも遅かったり、メモリ不足でエラーになったりする。 その解決策として「Self-hosted runner」を使って強めのインスタンスでビルド時間の短縮を実現しました。 欲しい環境 ・SpringNativeでNative-Buildできる環境 ・Dockerが使える AWSで利用したUbuntuのAMI 時期によって更新されていくので日付の部分は探す際には、違う日付になっている場合があります。 ubuntu-focal-20.04-amd64-server-20210430 docker-ceインストール #docker-ce install sudo apt install -y apt-transport-https ca-certificates curl software-properties-common curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - sudo apt-key fingerprint 0EBFCD88 sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" sudo apt update sudo apt install -y docker-ce sudo systemctl enable docker sudo systemctl start docker docker実行時にsudoしなくていいように sudo gpasswd -a $USER docker ここで、設定反映のため一度ログアウトして再ログインする dockerの実行テスト #docker test docker run hello-world SpringNativeのビルド環境を作っていく 必要なライブラリ 以下のライブラリのインストールが必要でした。 sudo apt install -y zip sudo apt install -y gcc GraalのJava11を入れる springのドキュメントをもとにセットアップしていきます。 #java11 graal curl -s "https://get.sdkman.io" | bash source "$HOME/.sdkman/bin/sdkman-init.sh" sdk install java 21.2.0.r11-grl sdk use java 21.2.0.r11-grl gu install native-image springの参考資料 sdkmanについてはこちら 自分は「maven」使っているのでインストール #maven sudo apt install -y maven Self-Hosted Runnerの設定 ここまで設定したら、GitHubActionsのSelf-hosted runnerとして使う設定をします。 Githubのリポジトリで「Setting > Actions > Runners」から「Add Runner」する。 「OS」と「Archtecture」は、利用したいインスタンスに合わせて設定する。 こんな感じで設定画面が出るので適宜設定する 設定完了したら実行 ターミナルを閉じても実行され続けるように、バックグランドで実行させる。 #self hosted runner. for background. cd ~/actions-runner nohup ./run.sh & 実行されているかプロセス確認 実行されていますね。 ps -a PID TTY TIME CMD 18425 pts/0 00:00:00 run.sh 18429 pts/0 00:00:00 Runner.Listener 18445 pts/0 00:00:00 ps 終了させたい場合はkill kill <PID> ssh接続を切って、githubからSelf-hosted runnerの稼働状況を確認します。 動いてますね 実際にCIを動かしてみます。 GithubActionsの使い方についてはここでは話しませんので、 公式のドキュメントなど見てみてください！ https://docs.github.com/ja/actions ビルド時間がどう変わったか GitHubの標準のRunnerの場合（ubuntu-20.04） 約19分（18分41秒） ローカルよりは早いけど、メモリが足りないときはどうしようもないです。 大きなプロジェクトになると、メモリエラーでビルド自体できなくなります。 Self-hosted runnerの場合（ubuntu-20.04 c5n.4xlarge 16vCpu/32GB） 約6分（5分51秒） 結構早くなりました！このくらいなら我慢できる。 もっとハイスペックなマシンを用意してスレッド設定をもっと増やしたら、もっと早くなるかも。 最後に 今回は、「Self-hosted runner」をEC2で作っています。 必要に合わせて起動したり停止したりする予定ですが、Fargateなどで必要な時だけ自動で起動、終わったら終了するようにするのもいいかもしれませんね。 時間ができたらやってみたいと思います。 余談 SpringNative化したRestAPI アプリケーションの起動時間は「0.134s」と爆速。 もともとは20秒程度だったので、爆速になりました。 kubernetesでのPod起動も数秒になりました！ここはProbe設定の調整が必要です。 オートスケールやノード障害時に正常なノードでのPodの起動処理もめちゃくちゃ早くなって、提供サービスの可用性が高くなるので良さそうです！ あと、「作業マシンのメモリを増強したら？」と言われたんですが、会社のリースのマシンでは箱開けちゃまずいので、それは無理っすｗ

昨日の記事からの続きとなります。 ◆事前準備編◆ 　1.macOSのデスクトップにtempフォルダを作る 　2.tempフォルダにccxtをpip3でインストールする 　3.既に作ったpythonプログラムを lambda_function.py へリネームしてtempフォルダに入れる 　4.lambda_function.py の先頭に指定プログラムを追記する 　5.ターミナルでzipでまとめる ◆Lambda編◆ 　6.AWSへログインし、5をアップロードする ◆EventBridge編◆ 　7.EventBridge (CloudWatch Events)に定期実行ルールを登録する 今回は7の説明をします。 手順 7.EventBridge (CloudWatch Events)に定期実行ルールを登録する 7-1.AWSのマネジメントコンソールヘログインします。 https://aws.amazon.com/jp/console/ 7-2.上部の検索バーに　Lambda　と入力します。Lambda　をクリックします。 7-3.手順6で作成した関数をクリックします。 7-4.[＋トリガーを追加] をクリックします。 7-5.[トリガの設定] で　[ EventBridge ]と入力します。 7-6.[新規ルールの作成] を選択し、ルール名に任意の名前を入力します。(例：everyday_1H) スケジュール式にcron形式で実行タイミングを記載します。 今回は1H毎に毎日Pythonを実行して欲しいので、以下のように書きます。 cron(0 * ? * * *) 最後に[追加]をクリックすると完成です。 cronの書き方 以下に公式の記載がありますが、英語なのでよくわからんって人向けにサンプルを記載します。 Minutes 分 Hours 時間 Day of month 何日 Month 月 Day of week 曜日 Year 年 Meaning 意味 0 10 * * ? * 毎日AM10時に実行 15 12 * * ? * 毎日PM12:15に実行 0 18 ? * MON-FRI * 毎週月〜金PM6時に実行 0 8 1 * ? * 毎月1日AM8時に実行 0/15 * * * ? * 15分毎に実行 0/5 8-17 ? * MON-FRI * 毎週月〜金AM8時〜PM5時55分まで5分毎に実行 最後に いかがでしたでしょうか。定期実行されましたでしょうか。 cronの書き方はくせがあるので、上記を見て理解して頂ければと思います。 PythonをAWSへ移行するまでを３つの記事で解説しました。 今日から私のオンプレmacOSはクラウドリフトされ、本番機からPython開発機となりました。 ご参考になれば幸いです。

参考URL https://qiita.com/enurinri/items/dece9d9020bf93315046 https://www.youtube.com/watch?v=FbnneJ17TA0

こんにちは、普段オンプレミス環境でのサーバ構築を行ってる海里です。 仕事の案件で、初めてAWSを触れることになりました。 しかし、AWSにてRHELサーバを初めて立てたとき、SSH接続ができなくて かなり苦戦したので忘備録として記述します。(ここに行き着くのに丸3日かかりました。) 誰の助けも借りることができないので自力でやらざる負えなかったので、むしろ褒めてほしい() VPCの構築 VPCを作成 [VPCを作成]をクリックする 必要な設定を入力し、[VPCを作成]をクリックする。 サブネットを作成 インターネットゲートウェイを作成する ルートテーブルを作成する 　ルートタブにインターネットゲートウェイを紐づける 　サブネットの関連付けタブでサブネットを関連付ける

504 Gateway timeout 解決方法 on AWS Webシステムで、バックエンドで少々長い時間が掛かる処理が終わるまで待つ必要があるケースがありますが、デフォルト設定だと、大体60秒程でタイムアウトとなり、「504 Gateway timeout」が発生するという事が多いです。 AWSで、ELB->Apache->PHPと言うよくある構成で、どの様に設定して行くと良いかをメモがてら残しておきます。 構成 クライアント(ブラウザ） -> ELB(ALB) -> WEB(Apache -> PHP) -> DB(RDS on MySQL) 今回、DBは割愛します。 タイムアウト調整 ユースケース次第ですがAWSのナレッジでは、KeepAliveTimeoutなどをロードバランサーのアイドルタイムアウトよりも長いキープアライブタイムアウトにするように推奨されています。 https://aws.amazon.com/jp/premiumsupport/knowledge-center/apache-backend-elb/ 例）無限にはできませんので、システム要件等で、程よいタイムアウト値を検討する必要があります。 クライアント（デフォルト：ブラウザ依存）　＜　ELB（60)　＜　WEB(Apache 120)　＜　WEB(PHP　120) それぞれ設定すべき箇所 少々極端ですが、10分(600秒)タイムアウトさせたくないとします。 クライアント(ブラウザ）　※多分ここで調整することは無いと思います。 Chrome 調べましたが、Chromeでタイムアウト設定を変更することはできないようです タイムアウトが何秒なのかなどのドキュメントも見当たらない・・・ Firefox about:configから、「network.http.connection-timeout」を調整 IE レジストリで、 KeepAliveTimeout、ServerInfoTimeoutのDWORD値を調整 https://docs.microsoft.com/en-US/troubleshoot/browsers/change-keep-alive-time-out Safari SafariNoTimeoutをアプリとしてインストールすると可能とのこと ELB アイドルタイムアウト Apache /etc/httpd/conf.d/aws_elb.confを作成して設定 例）600秒なので、1.25倍して、750秒にしてみました。 /etc/httpd/conf.d/aws_elb.conf # クライアントヘッダータイムアウト # ロードバランサーでアイドル接続を適切に切断できるように、ロードバランサーに設定されたアイドルタイムアウトよりも大きな値に設定します。 # ロードバランサーに適切に通知せずに、バックエンドサーバーで接続を終了すると、504 エラーが表示されることがあります。 Timeout 750 # キープアライブ # CPU 使用率を削減し、応答時間を改善するには、キープアライブをオンにします。 # キープアライブをオンにすると、ロードバランサーで、HTTP リクエストの度に新しい TCP 接続を確立する必要がありません。 KeepAlive On # キープアライブオプションが有効になっている場合は、ロードバランサーのアイドルタイムアウトよりも長いキープアライブタイムアウトを選択します。 KeepAliveTimeout 750 # キープアライブリクエストの最大数 # このオプションでは、キープアライブがオンになった時に単一の TCP 接続で処理するリクエストの数を設定します。 # リソースの使用を最適化するために、キープアライブリクエストの最大数は 100 以上に設定します。 MaxKeepAliveRequests 100 # AcceptFilter # AcceptFilter はデフォルトで有効になっており、接続に TCP_DEFER_ACCEPT オプションを使用するよう Apache に指示します。 # この設定では、TCP ソケットが「ハーフオープン」状態になることがあります。 # この場合、ロードバランサーでは接続が確立されているが、バックエンドインスタンスでは接続が確立されていないことを前提とします。 # ハーフオープン接続は、性能が高くないロードバランサーで最も一般的です。この場合、使用前の接続に時間がかかります。 AcceptFilter http none # ELB access_log format LogFormat "%{X-Forwarded-For}i %h %l %u %t \"%r\" %>s %b %D \"%{Referer}i\" \"%{User-Agent}i\"" combined # Set over AWS ELB connection time out default 60s # 長時間にわたる少量ずつの読み込み/書き込み処理を悪用する攻撃 (Slowloris など) に対して接続を自動的に閉じる RequestReadTimeout header=750 PHP おなじみのphp.iniでmax_execution_timeの値で定義する方法 ただし、全体的にスクリプトが実行可能な秒数が伸びてしまうので注意が必要 /etc/php.ini ;;;;;;;;;;;;;;;;;;; ; Resource Limits ; ;;;;;;;;;;;;;;;;;;; ; Maximum execution time of each script, in seconds ; http://php.net/max-execution-time ; Note: This directive is hardcoded to 0 for the CLI SAPI max_execution_time = 60 処理中に、set_time_limit(int $seconds): bool　で実行時間の最大値を制限する <?php set_time_limit(750); while ($i<=10) { echo "i=$i "; sleep(100); $i++; } ?>

はじめに htmlフォームからPOST送信して、SESを使って、通知メールが飛び、リダイレクトページを返却するお問い合わせフォームを実装した。実装手順を忘れないように、備忘として残しておく。 ※当初リターンメールを返す想定だったので、SESにしているが、SNSでもいい HTMLの入力フォーム 値をPOSTして、API Gatewayに渡すためのサンプルフォーム ※API Gatewayのエンドポイントの部分は後ほど修正する必要あり sample.html <!DOCTYPEhtml> <html lang="ja"> <head> <meta charset="UTF-8"> <title>お問い合わせフォーム</title> </head> <body> <header> <h1>お問い合わせフォーム</h1> </header> <article> <form action="API Gatewayのエンドポイント" method="post" accept-charset="utf-8"> <input type="text" name="name" placeholder="name"/> <input type="text" name="ruby" placeholder="ruby"/> <input type="email" name="email_address" placeholder="email_address"/> <input type="text" name="contents" placeholder="contents" maxlength='250'/> <input type="submit" value="送信"> </form> </article> </body> </html> Lambda API Gatewayの実装の前に、Lambda関数を実装しておく。 ・コンソール画面＞Lambda＞関数の作成 ・関数名、関数で使う言語（今回はPython）、実行ロール（SESFullAccess、AWSLambda_FullAccess）を指定。今回はあらかじめ作っていたロールを付与しているが、新しいロール作成を作るもよし。 ・作成したら、実際に関数の処理をコーディングする。 　最初はテンプレで、「Hello from Lambda!」を返すプログラムになっているので、以下に修正。 sample.py import boto3 import json import urllib.parse #定数(Lambdaの環境変数に設定しても良いが今回はベタがき) FROM_MAIL = 'SESに認証させる送信元メールアドレス' TO_MAIL = 'SESに認証させる送信先メールアドレス' REGION = 'ap-northeast-1' SUBJECT = '★要対応★お問い合わせメールへのご対応をお願いします' #送信処理 def send_email(source, to, subject, body): client = boto3.client('ses', region_name=REGION) response = client.send_email( Source=source, Destination={ 'ToAddresses': [ to, ] }, Message={ 'Subject': { 'Data': subject, }, 'Body': { 'Text': { 'Data': body, }, } } ) return response #ハンドラー def lambda_handler(event, context): #eventの中の値をデコードして取得 #API Gatewayがvalueをエンコードするため、デコードした値を代入する name = urllib.parse.unquote_plus(event['name']) ruby = urllib.parse.unquote_plus(event['ruby']) email_address = urllib.parse.unquote_plus(event['email_address']) contents = urllib.parse.unquote_plus(event['contents']) #固定メッセージ message = f'下記のお客様よりお問い合わせをいただきました。\n\n======================================\nお名前：{name}\nフリガナ：{ruby}\nメールアドレス：{email_address}\n問い合わせ内容：{contents}\n\n======================================\n\n※このメールはシステムから自動送信されています\n' r = send_email(FROM_MAIL, TO_MAIL, SUBJECT, message) #リダイレクト return { "statusCode": 302, "body": 'redirect', "Location": 'リダイレクト先.html' } API Gateway お問い合わせフォームからリクエストを受け取って、Lambdaに渡すためのAPI Gatewayを実装する。 ・コンソール画面＞API Gateway＞APIの作成 ・REST API＞構築 ・API名を入力する画面になるので、TestAPIと記載して、他はデフォルトのまま、APIの作成 ・アクション＞リソースの作成＞リソース名を記載＞リソースの作成 ・アクション＞メソッドの作成＞POST＞Lambda関数に先ほど作成した関数名入力＞保存 ※ちなみに、「Lambdaプロキシ統合の使用」にチェックを入れて、値をLambda関数に渡すことも可能だが、今回はマッピングテンプレートを使用する。 Lambdaプロキシ統合を使用する場合の参考記事は以下。（この記事では割愛） 参考記事：https://cres-tech.hatenablog.com/entry/2020/10/03/112402 ・統合リクエスト＞マッピングテンプレートに以下を記載する。 { #foreach( $token in $input.path('$').split('&') ) #set( $keyVal = $token.split('=') ) #set( $keyValSize = $keyVal.size() ) #if( $keyValSize >= 1 ) #set( $key = $util.urlDecode($keyVal[0]) ) #if( $keyValSize >= 2 ) #set( $val = $keyVal[1] ) #else #set( $val = '' ) #end "$key": "$val"#if($foreach.hasNext),#end #end #end } リダイレクト メール送信後にリダイレクトさせる場合には、もう1手順必要。 ・メソッドレスポンス＞以下のように302リダイレクトステータスを指定＞200ステータスを削除する ・統合レスポンス＞302ステータスを追加する＞200ステータスを削除する ・ヘッダーのマッピング＞レスポンスヘッダーに「Location」と記載＞マッピングの値に「integration.response.body.Location」を指定 ・アクション＞デプロイ（デプロイステージは新しいステージでdevと記載） ・最初に作ったHTMLのURL呼び出し部分に以下のエンドポイントを指定する SES 今回は最初にリターンメールをメール送信者に返すつもりだったので、SESにしたが、社内通知メールならSNSでもいい。 ・AWSコンソールからSES＞Email Addrees＞Verify a New Email Address ・送信元メールアドレスを指定する＞Verify This Email Address（送信先メールアドレスも同手順） ・AWSからメールが来るので、リンクを踏むと、Verification Statusがverifiedになる。（送信先メールアドレスも同手順） HTMLから値を入力して、認証先メールアドレスにメールが飛んで、リダイレクト先のページに遷移すれば、実装完了！ その他 SESはデフォルトの設定だと認証されたアドレスにしかメールを送れない。問い合わせ者へのリターンメールを返す場合は、AWSにアカウントをサンドボックス外に移動してもらう申請をする必要がある。その場合の参考記事は以下。（この記事では割愛） 参考記事①：https://docs.aws.amazon.com/ja_jp/ses/latest/DeveloperGuide/request-production-access.html 参考記事②：https://bbh.bz/2019/08/20/ses-restriction-relaxation/ 参考記事③：https://qiita.com/comefigo/items/454091c595aa56c43751

※ 本稿は Tech Inside Drecom に掲載された記事、「様々な障害に耐えうるSSRのインフラを設計しました！」の Qiita 出張版です。 はじめに こんにちは！enza SREチームのmendと申します！ 現在enzaではサーバーサイドレンダリング(=SSR)の導入を進めております！ SSRを導入するにあたり、CloudFront + SSRのサーバー では CloudFront + S3 の構成と比べて複雑になってしまうため、様々な障害によってページが見れなくなってしまう要因が増えてしまいます。 今回はSSRを実現しつつ、様々な障害が起こってもページを見ることができるインフラを設計しましたのでご紹介させていただきます！ SSRとは SSRはServer Side Rendering(サーバーサイドレンダリング)の略称で、クライアント側でJavaScript等を動かしてHTMLを生成するのではなく、サーバー側でJavaScript等を動かしてHTMLを生成することを言います。厳密にはもっと様々な解釈や詳細な定義がありますが、少なくとも今回の記事ではサーバー側でJavaScript等を動かしてHTMLを生成することをSSRとします。 SSRのメリット SSRのメリットとして、SPAでのSEO対策が簡単になるメリットがあります。 SPAでは一つのHTMLをJavaScriptで動的に変更して画面を描画しますが、検索エンジンのクローラーによってはJavaScriptを読み込まなかったり、意図した通りに読み込まれない場合があります。 このような問題に対し、SSRを使用することで検索エンジンが読み込むページをサーバーで処理されたHTMLにすることができるようになり、SPAでも細かなSEO対策ができるようになります。 インフラから見たSSRで必要な条件 インフラ視点からSSRを実現するために必要な条件をまとめてみると、以下のようになります。 サーバーを動かす環境を用意する SSRを行うサーバーを動かす環境ですが今回はKubernetes環境上のPodで動かすようにします。 前回の記事ダウンタイムなしでEC2からEKSへ移行しました！に記載したとおり、enzaではシステムの一部にEKSで構築したKubernetes環境を使用しております。 SSRのサーバーでレンダリングされたHTMLはCDN側でキャッシュされるため、通常のAPIサーバー等と比較するとアクセス数が少ないことから、マシンリソースを管理しやすいKubernetes環境のPodで動かすことにしました。 どのようなImageを使用してSSRを行うか、といったような具体的な実装に関わる内容は今回は省略します。 CDNの設定を変える SSR導入前の設定では、CDNであるCloudFrontのOriginはSPAの静的ファイルを置いているS3を参照しております。 enzaではCDNにAWSのサービスの一つであるCloudFrontを使用していますが、このままの設定ではSSRを行うPodを配置しているKubernetesクラスタに対してアクセスが届きません。 そのためCloudFrontに対してMulti Originの設定を行い、S3, Kubernetesクラスタ両方にアクセスできるようにします。 Multi Originとは Multi OriginとはCloudFrontに対して複数のOriginを設定できる機能になります。 複数のOriginを設定できることで、1つのOriginが使用できなくなったときに予め設定しておいたもう一方のOriginにアクセスを割り振るといったことが可能になります。 さらにこちらのMulti Origin機能、なんとBehaviorにPath Patternを設定することでリクエストのPathのパターンに応じてOriginのアクセスを分けることができます。 origin1にはS3, origin2にはEC2インスタンスをそれぞれ設定したと仮定したうえで、例として以下のリクエストがあったとします。 reqA：https://example.com/aaa reqB：https://example.com/bbb reqC：https://example.com/image.jpg Multi Origin機能を使いBehaviorでPath Patternを設定しておくと、CloudFrontに対してreqAとreqBのようなリクエストではEC2インスタンスからレスポンスを返し、reqCのような拡張子がついたリクエストが届いた場合はS3からレスポンスを返すといった細かい設定が可能です。 こちらの機能を使用し、実際にSSRを導入する場合のインフラを設計してみました。 インフラ設計 まずSSRを導入する前のインフラがこちらになります。 この画像の通り現在enzaはCloudFrontを使用しており、CloudFrontのOriginとしてbucketのS3を1つ設定しており、 cloudfrontで静的webページを公開する方法としてはかなり基本的な設定となっております。 ここからSSRを行えるように大改造を行います。大改造後はこちらです。 SSRを実現するため、上記画像に示したように以下の内容で変更を行います。 /*.*のような特定の拡張子以外がついたリクエストは既存と同様にS3から静的ファイルを返す /や/*のような拡張子のないリクエストと/*.htmlはSSRした結果を返すようにSSRのドメインに向ける CloudFrontに対してSSRのリクエストを渡すドメインとしてRoute53レコードをMulti Originに設定 Route53レコードにALBを紐付け ALBのターゲットグループにEKSで構成したKubernetesクラスタのワーカーノードを指定 ターゲットグループのポートにSSRを行うPodにアクセスするServiceのNodePortを指定 このような設計とすることで、後述する障害に耐えられる構成になっております。 上記のインフラを設計する際には、S3だけでは起きることがなかった障害を防ぎつつ、移行後にも高い可用性を保てるように設計を行いました。 考えられる障害 導入後に発生すると考えられる障害と、障害による影響を防ぐための工夫について説明したいと思います。 ALBの障害の対策 AWSでは滅多にありませんが、ALBが正常に動作しない障害が起こることがあります。 主にAZ単位で起こるものですが、万が一SSRで使用するALBに障害があるとSSRを使用するページ全てが見れなくなる可能性があります。 このような問題に対し、ALBの障害が起こったときでもページを見れるようにするためCloudFrontのOrigin Failoverを使用します。 Origin Failover Origin FailoverはCloudFrontに設定したOriginから任意のステータスコードが返って来たりタイムアウトした場合、もう一方のOriginでリクエストを処理するように設定する機能になります。 こちらの機能を使用し、もしALB側で問題が起こりレスポンスが異常だった場合はこれまで同様にS3から返すよう設定しておきます。 ワーカーノードによる障害の対策 ワーカーノードの実態はEC2インスタンスになります。 EC2インスタンスはEC2側の障害発生頻度よりもAWSの障害時以外でEC2インスタンスの終了するペースが早く、インスタンスの終了がユーザーにとっての障害の原因になりやすくなってしまいます。 そのような場合はKubernetes側のDeploymentやHorizontal Pod Autoscaler, PodDisruptionBudgetを使用し、複数のPodを複数のワーカーノードで起動するようにすることでワーカーノードの障害が起こった際でも別のワーカーノードからリクエストを処理することができます。 Podレベルの障害 KubernetesでPodを動かす場合、アプリケーション側の問題が起きたり、Podが使用するマシンリソースが割り当てられないなど様々な要因でPod自体が起動できなくなってしまう状態が考えられます。 もしKubernetes内で設定したSSRのServiceに紐付けられるPodが全て動作しない場合でServiceに対してリクエストが届いた場合はリクエストに対して502が返却されます。 このような問題が起こったとき、ただOriginを設定しただけではユーザーまで502エラーが伝わってしまうため、上記で紹介したCloudFrontのOrigin Failover機能を使用します。最終的にCloudFrontに502エラーが返ってきた際には別のOriginにアクセスするように設定することでユーザーは変わらずS3から返されたページをみることができます。 まとめ SSRを行うためのインフラを構築するにあたり、CloudFrontにKubernetesを組み合わせることで様々な障害に耐えうるインフラの設計を行いました。 CloudFrontのOriginにS3を設定する組み合わせは静的サイトを公開するにあたってよくある組み合わせであり、高い可用性を持つ構成でもあります。 本来SSRを導入する際にはSSRを行うサーバーのみをOriginに設定すると思われますが、その状態ではこれまでの高い可用性が犠牲となってしまいます。しかし今回はCloudFrontが持つMulti Originの機能を利用することで、S3が持つ高い可用性をベースにSSR機能を組み合わせることができるため、ぜひSSRを導入する際には参考にしてみてください。 Tech Inside Drecom の最新の情報は Facebook や Twitter からお届けしています、フォローよろしくおねがいします！ Twitter: @DRECOM_TECH Facebook: tech.inside.drecom ※ その他の Tech Inside Drecom の記事は、コチラからお探しいただけます！!

ソース Bashスクリプト(gist) #!/bin/bash set -eu # Prerequisite # - aws cli # - session-manager-plugin # - jq selectProfile(){ select selected in `aws configure list-profiles` do break done echo $selected } selectCluster(){ select selected in `aws ecs list-clusters --profile $profile|jq -r ".clusterArns[]"|sort|cut -d "/" -f 2` do break done echo $selected } selectService(){ select selected in `aws ecs list-services --profile $profile --cluster $cluster|jq -r ".serviceArns[]"|sort` do break done echo $selected } selectTask(){ select selected in `aws ecs list-tasks --cluster $cluster --profile $profile --service-name $service --desired-status RUNNING |jq -r '.taskArns[]'|sort` do break done echo $selected } selectContainer(){ select selected in `aws ecs describe-tasks --cluster $cluster --tasks $task --profile $profile|jq -r ".tasks[].containers[].name"|sort` do break done echo $selected } colorEcho(){ red='\033[0;31m' green='\033[0;32m' yellow='\033[0;33m' reset='\033[0m' if echo $@ | egrep -q "prd|prod"; then color=$red elif echo $@ | egrep -q "stg|stage|staging"; then color=$yellow else color=$green fi echo -e "${color}$@${reset}" } main(){ echo "Select aws profile." profile=`selectProfile` colorEcho profile: $profile echo echo "Select cluster." cluster=`selectCluster` colorEcho cluster: $cluster echo echo "Select service." service=`selectService` colorEcho service: $service echo echo "Select task." task=`selectTask` colorEcho task: $task echo echo "Select container." container=`selectContainer` colorEcho container: $container echo cmd="aws ecs execute-command --profile $profile --cluster $cluster --container $container --task $task --interactive --command '/bin/sh'" colorEcho $cmd $cmd } main 使い方 # ダウンロードして実行します wget https://gist.githubusercontent.com/yuki777/640cba3e0a68587c36165b8a87d25390/raw/0aa9e48bc1e29e9a5b7c888cc16067dcccd6cc0a/sssh chmod 744 sssh ./sssh # AWSプロファイルを選択します Select aws profile. 1) default 2) foo-bar #? 2 profile: foo-bar # ECSクラスタを選択します Select cluster. 1) dev-foo-bar-cluster 9) prod-foo-app-cluster 2) prd-foo-hoge-ad-cluster 10) stg-foo-app-cluster 3) prd-foo-hoge-cluster 11) stg-foo-hoge-cluster 4) prd-foo-piyo2021-ad-cluster 12) stg-foo-piyo2021-cluster 5) prd-foo-piyo2021-cluster 13) stg-foo-bar-cluster 6) prd-foo-bar-ad-cluster 14) stg-foo-tags-cluster 7) prd-foo-bar-cluster 15) hoge-foo-bar-cluster 8) prd-foo-tags-cluster #? 1 cluster: dev-foo-bar-cluster # ECSサービスを選択します 1) arn:aws:ecs:ap-northeast-1:************:service/dev-foo-bar-cluster/dev-foo-qa-1125-service 2) arn:aws:ecs:ap-northeast-1:************:service/dev-foo-bar-cluster/dev-foo-qa-1206-service 3) arn:aws:ecs:ap-northeast-1:************:service/dev-foo-bar-cluster/dev-foo-qa-1249-service 4) arn:aws:ecs:ap-northeast-1:************:service/dev-foo-bar-cluster/dev-foo-qa-1275-service 5) arn:aws:ecs:ap-northeast-1:************:service/dev-foo-bar-cluster/dev-foo-qa-1323-service 6) arn:aws:ecs:ap-northeast-1:************:service/dev-foo-bar-cluster/dev-foo-qa-1348-service 7) arn:aws:ecs:ap-northeast-1:************:service/dev-foo-bar-cluster/dev-foo-qa-1349-service 8) arn:aws:ecs:ap-northeast-1:************:service/dev-foo-bar-cluster/dev-foo-qa-1384-service 9) arn:aws:ecs:ap-northeast-1:************:service/dev-foo-bar-cluster/dev-foo-qa-1386-service 10) arn:aws:ecs:ap-northeast-1:************:service/dev-foo-bar-cluster/dev-foo-qa-1391-service 11) arn:aws:ecs:ap-northeast-1:************:service/dev-foo-bar-cluster/dev-foo-qa-1397-service 12) arn:aws:ecs:ap-northeast-1:************:service/dev-foo-bar-cluster/dev-foo-qa-1399-service 13) arn:aws:ecs:ap-northeast-1:************:service/dev-foo-bar-cluster/dev-foo-qa-1412-service 14) arn:aws:ecs:ap-northeast-1:************:service/dev-foo-bar-cluster/dev-foo-qa-1413-service 15) arn:aws:ecs:ap-northeast-1:************:service/dev-foo-bar-cluster/dev-foo-qa-1419-service 16) arn:aws:ecs:ap-northeast-1:************:service/dev-foo-bar-cluster/dev-foo-qa-1420-service 17) arn:aws:ecs:ap-northeast-1:************:service/dev-foo-bar-cluster/dev-foo-service #? 16 service: arn:aws:ecs:ap-northeast-1:************:service/dev-foo-bar-cluster/dev-foo-bar-qa-1420-service # ECSタスクを選択します 1) arn:aws:ecs:ap-northeast-1:************:task/dev-foo-bar-cluster/******************************** #? 1 task: arn:aws:ecs:ap-northeast-1:************:task/dev-foo-bar-cluster/******************************** # ECSコンテナを選択します 1) container-foo 2) container-bar 3) container-hoge 4) container-piyo #? 1 container: container-foo # 実行されるコマンドです aws ecs execute-command --profile foo-bar --cluster dev-foo-bar-cluster --container container-foo --task arn:aws:ecs:ap-northeast-1:************:task/dev-foo-bar-cluster/******************************** --interactive --command '/bin/sh' The Session Manager plugin was installed successfully. Use the AWS CLI to start a session. # sessionが開始されて'/bin/sh'コマンドが実行されます Starting session with SessionId: ecs-execute-command-***************** /path/to/home # :) 参考 Amazon ECS で、Amazon EC2 または AWS Fargate で実行されているコンテナでのコマンドの実行が可能に 実行中のコンテナに乗り込んでコマンドを実行できる「ECS Exec」が公開されました ecs - AWS CLI 1.20.36 Command Reference

対象者 Certbotを使用してhttps化した方 https接続した際に504 Gateway Timeoutと表示される方 目的 504 Gateway Timeoutのバグを修正してブラウザにアクセスする 前提 下記の記事をもとにしています。 実際の手順と実例 1.結論 キャッシュが溜まっていたせいでhttps接続できていなかった。 というめちゃくちゃ単純なバグだったのですが、 結構ハマったので記事にしてみました。 2.原因 ページが表示されず、しばらくするとブラウザに504 Gateway Timeoutと表示されてしまう。 そもそも、504 Gateway Timeoutとは下記の通りです。 HyperText Transfer Protocol (HTTP) 504 Gateway Timeout サーバーエラーレスポンスコードは、サーバーがゲートウェイまたはプロキシとして機能しているときに、リクエストを完了するために必要な上流のサーバーからのレスポンスが時間内に得られなかったことを示します。 https化しているのになぜhttp接続を試みているのか。 原因としてはサーバーのキャッシュが溜まりすぎていて、 なかなか接続できずに、httpを探しにいってしまったから。 キャッシュとは ブラウザが一度表示したWebページのデータを保存しておいて、次に同じページを表示する際、一度目より素早く表示してくれる仕組みのことです。 下記の記事を参考にさせて頂きました。 3.解決策 ３通りあります。 1. シークレットウインドウで開く 2. キャッシュとクッキーを削除 3. 別なWebブラウザで開く 2.でChrome使用中の方は下記を参考にするとできます Chromeを使用している方はSafariやFirefoxを使用するとうまくWebサイトが開けるかもしれません。 参照 キャッシュと Cookie の消去 キャッシュとは？Webサイト高速化にかかせない機能をご紹介！ 504 Gateway Timeout - HTTP | MDN

今回はプライベートサブネットとパブリックサブネットを複数のAZに配置する、よくある構成のネットワークをCloudFormationで作成していきます。 ■ テンプレート sample-network-multi-az.yml AWSTemplateFormatVersion: '2010-09-09' ## # パラメータ定義: https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html ## Parameters: CidrPrefix: Type: String Outputs: VPCId: Value: !Ref VPC PublicSubnet01Id: Value: !Ref PublicSubnet01 PublicSubnet02Id: Value: !Ref PublicSubnet02 PrivateSubnet01Id: Value: !Ref PrivateSubnet01 PrivateSubnet02Id: Value: !Ref PrivateSubnet02 VPC: Value: !GetAtt VPC.CidrBlock Resources: ## # vpc: https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-vpc.html ## VPC: Type: AWS::EC2::VPC Properties: CidrBlock: !Sub ${CidrPrefix}.0.0/16 Tags: - Key: Name Value: !Sub ${AWS::StackName}-vpc ## # サブネット: https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-subnet.html ## PublicSubnet01: Type: AWS::EC2::Subnet Properties: CidrBlock: !Sub ${CidrPrefix}.10.0/24 AvailabilityZone: ap-northeast-1a MapPublicIpOnLaunch: false # このサブネットで起動されたインスタンスが起動時にパブリックIPを設定するか(default = false) VpcId: !Ref VPC Tags: - Key: Name Value: !Sub ${AWS::StackName}-public-subnet-01 PublicSubnet02: Type: AWS::EC2::Subnet Properties: CidrBlock: !Sub ${CidrPrefix}.20.0/24 AvailabilityZone: ap-northeast-1c MapPublicIpOnLaunch: false VpcId: !Ref VPC Tags: - Key: Name Value: !Sub ${AWS::StackName}-public-subnet-02 PrivateSubnet01: Type: AWS::EC2::Subnet Properties: CidrBlock: !Sub ${CidrPrefix}.11.0/24 AvailabilityZone: ap-northeast-1a MapPublicIpOnLaunch: false VpcId: !Ref VPC Tags: - Key: Name Value: !Sub ${AWS::StackName}-private-subnet-01 PrivateSubnet02: Type: AWS::EC2::Subnet Properties: CidrBlock: !Sub ${CidrPrefix}.21.0/24 AvailabilityZone: ap-northeast-1c MapPublicIpOnLaunch: false VpcId: !Ref VPC Tags: - Key: Name Value: !Sub ${AWS::StackName}-private-subnet-02 ## # インターネットゲートウェイ: https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-internetgateway.html ## InternetGateway: Type: AWS::EC2::InternetGateway Properties: Tags: - Key: Name Value: !Sub ${AWS::StackName}-igw # VPCにインターネットゲートウェイをアタッチ: https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-vpc-gateway-attachment.html AttachInternetGateway: Type: AWS::EC2::VPCGatewayAttachment Properties: VpcId: !Ref VPC InternetGatewayId: !Ref InternetGateway ## # ElasticIp: https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-eip.html ## EipNgw01: # NatGateway01用のグローバルIP Type: AWS::EC2::EIP Properties: Domain: vpc Tags: - Key: Name Value: !Sub ${AWS::StackName}-eip-ngw01 EipNgw02: # NatGateway02用のグローバルIP Type: AWS::EC2::EIP Properties: Domain: vpc Tags: - Key: Name Value: !Sub ${AWS::StackName}-eip-ngw02 ## # NATゲートウェイ: https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-natgateway.html ## NatGateway01: Type: AWS::EC2::NatGateway Properties: AllocationId: !GetAtt EipNgw01.AllocationId SubnetId: !Ref PublicSubnet01 Tags: - Key: Name Value: !Sub ${AWS::StackName}-ngw-01 NatGateway02: Type: AWS::EC2::NatGateway Properties: AllocationId: !GetAtt EipNgw02.AllocationId SubnetId: !Ref PublicSubnet02 Tags: - Key: Name Value: !Sub ${AWS::StackName}-ngw-02 ## # ルートテーブル: https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-route-table.html ## PublicRouteTable: Type: AWS::EC2::RouteTable DependsOn: AttachInternetGateway Properties: VpcId: !Ref VPC Tags: - Key: Name Value: !Sub ${AWS::StackName}-public-rt-01 PrivateRouteTable01: Type: AWS::EC2::RouteTable DependsOn: AttachInternetGateway Properties: VpcId: !Ref VPC Tags: - Key: Name Value: !Sub ${AWS::StackName}-private-rt-01 PrivateRouteTable02: Type: AWS::EC2::RouteTable DependsOn: AttachInternetGateway Properties: VpcId: !Ref VPC Tags: - Key: Name Value: !Sub ${AWS::StackName}-private-rt-02 # サブネットとルートテーブルの紐づけ: https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-subnet-route-table-assoc.html PublicRouteAssoc01: Type: AWS::EC2::SubnetRouteTableAssociation Properties: RouteTableId: !Ref PublicRouteTable SubnetId: !Ref PublicSubnet01 PublicRouteAssoc02: Type: AWS::EC2::SubnetRouteTableAssociation Properties: RouteTableId: !Ref PublicRouteTable SubnetId: !Ref PublicSubnet02 PrivateRouteAssoc01: Type: AWS::EC2::SubnetRouteTableAssociation Properties: RouteTableId: !Ref PrivateRouteTable01 SubnetId: !Ref PrivateSubnet01 PrivateRouteAssoc02: Type: AWS::EC2::SubnetRouteTableAssociation Properties: RouteTableId: !Ref PrivateRouteTable02 SubnetId: !Ref PrivateSubnet02 # ルート定義: https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-route.html PublicRoute: # パブリックサブネット用のルート定義 (パブリックサブネット->インターネットの通信は直接InternetGatewayをゲートウェイにします) Type: AWS::EC2::Route Properties: RouteTableId: !Ref PublicRouteTable DestinationCidrBlock: 0.0.0.0/0 GatewayId: !Ref InternetGateway PrivateRoute01: # PrivateSubnet01用のルート定義 (プライベートサブネット->インターネットの通信はNATGatewayを経由させます) Type: AWS::EC2::Route Properties: RouteTableId: !Ref PrivateRouteTable01 DestinationCidrBlock: 0.0.0.0/0 NatGatewayId: !Ref NatGateway01 PrivateRoute02: # PrivateSubnet02用のルート定義 (プライベートサブネット->インターネットの通信はNATGatewayを経由させます) Type: AWS::EC2::Route Properties: RouteTableId: !Ref PrivateRouteTable02 DestinationCidrBlock: 0.0.0.0/0 NatGatewayId: !Ref NatGateway02 ■ スタック作成・削除 # スタックの作成 aws cloudformation create-stack \ --stack-name sample-network \ --template-body file://./sample-network-multi-az.yml \ --parameters "ParameterKey=CidrPrefix,ParameterValue=10.109" # スタックの情報を表示 aws cloudformation describe-stacks --stack-name sample-network # スタックの削除 aws cloudformation delete-stack --stack-name sample-network