「VPC」を含む日記 RSS

はてなキーワード: VPCとは

2024-01-17

エンジニア6年目、プログラミング10年目でインフラに苦手意識があって触らなかったせいで、今更(?)AWSVPCとは、NATゲートウェイとは、料金はいくらか等を学んでいる

NATゲートウェイ高いなぁとか、VPCエンドポイントの方がいいのかなとか、そもそもパブリックサブネットEC2置いて良くない?とか

来月からパブリックIPv4課金されるようになるからIPv6だけに極力絞りたいなぁとか、それをCDKで構築しようとしたが何だかんだ嵌ったり……

そうこうしてるだけで1週間経過した

2023-03-01

AWSソリューションアーキテクトむずすぎ

SAA簡単みたいな風潮あるけどむずくないかこれ

AWSvpcとlamdaとcognitoとS3くらい触ったことあるからまあできるっしょって気持ちで申し込んだけど勉強し始めたら知らんサービス多すぎてはげそう

受かってる人普通にすごいと思う

2022-09-03

[]2022年8月はてブあとで読むトップ30リスト

はてブホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ

312あとで/1768users 漫画で学ぶNISAiDeCo資産形成ポイント解説日経電子

243あとで/1598users 45分間で「ユーザー中心のものづくり」ができるまで詰め込む | Yoshiki Hayama | slideshare

233あとで/1752users 見積提案書に書いておくと不幸を減らせる前提条件 | Atsushi Nakamura | Zenn

215あとで/1290users サイバーエージェントが公開した“300ページ級のUnity技術書”がスゴい!しかも誰でも無料で読める|Unity Japanユニティテクノロジーズ・ジャパン)|note

210あとで/1775users なぜ投資をさっさと始めないのか - 本しゃぶり

209あとで/1465users 「何を言っているのか分からない」と言われないための「伝え方」のノウハウ - Qiita

196あとで/1631users 引越しが決まったらやるべきことのあれこれがめっちゃ参考になると話題「ありがてぇ…」補足あり | Togetter

194あとで/1830users やばすぎるAI画像生成サービス「Stable Diffusion」始まる。 【簡単解説 & 応用 & Prompt付生成事例集】|やまかず|note

189あとで/1680users 鈴木孝佳|姿勢改善オンラインレッスン on Twitter: "「あれこれストレッチ面倒だから1個教えてくれ」に対する解はこれです。「世界で最も偉大なストレッチ」と名前がつくだけあって、フルコンボ感ある。 https://t.co/UbfDw4F8SN"

187あとで/1623users 相手に動いてもらえないのは、一言目で“地雷”を踏んでいるから 仕事でも私生活でも役に立つ、人を動かす「伝え方」の極意 | 高橋浩一、荒木博行 | logmi

184あとで/948users Amazon VPCを「これでもか!」というくらい丁寧に解説 - Qiita

168あとで/919users 「リーダー作法マネジメントに限らず、エンジニアとして仕事作法について書かれた良書 | hurutoriya

161あとで/1231users スタンフォード大学無料提供している英語プログラムがすごすぎる...様々な高校生向け教育プログラムをまとめました | Togetter

161あとで/1444users Seiya on Twitter: "クイーンズランド大学が開発したHIITがすごい。HIIT WBというエクササイズで、たった4分間の運動で30分の有酸素運動を遥かに凌ぐ効果を発揮する。心肺機能筋肉量の増加、脂肪減まで期待でき、抗老化に繋がる。動画をそのまま真似し… https://t.co/FWvRp0RAaR"

159あとで/1503users 精度はGoogle翻訳を越える… 無料国産「TexTra」が地味にスゴイ | ビジネスジャーナル

156あとで/1582users 横浜中華街いろいろ食べたくなるガイド|47AgDragon(しるどら|note

155あとで/736users 設計の考え方とやり方 | 増田 亨 | SpeakerDeck

151あとで/1290users なぜ日本郊外には「タダ同然の住宅地」が大量にあるのか…「限界分譲地」という大問題告発する 無責任の体系によって「都市の荒廃」が進んでいる | PRESIDENT Online

151あとで/1225users 『りぼん編集部が作った「生理カンペキBOOK」が永久保存版すぎる。無料公開した思いを聞いた | HUFFPOST

147あとで/1209users Seiya on Twitter: "自宅にこもり切りの超運動不足の方、筋トレ初心者の方へ。まずは2分だけ動画の真似をしてみて欲しい。難易度は低いが、鈍り切った体に刺激が入り、眠っていた身体の活力を取り戻すキッカケになると思う。 「独房式・脂肪燃焼全身サーキット新… https://t.co/pMQHBJAlIA"

139あとで/1768users 世界変革の前夜は思ったより静か|深津 貴之 (fladdict)|note

133あとで/1188users 「酒場で見ず知らずの人と親しく話し、取材する方法」を書いた朝日新聞記者記述面白かった(「ルポ トランプ王国2」) - INVISIBLE D. ーQUIET & COLORFUL PLACE-

128あとで/1292users 魔術として理解するお絵描きAI講座|深津 貴之 (fladdict)|note

127あとで/1379users 夫が裏垢で70人と不倫していたのが発覚した日の話①|ego@離婚協議中|note

126あとで/1146users 三谷幸喜さんが勧める「読書感想文」の書き方。「子どもの頃知りたかった」と反響呼ぶ | HUFFPOST

123あとで/811users キャリアアッププログラムGoogle Career Certificates」日本版を開始 | Google Japan Blog

122あとで/1083users マルク on Twitter: "元銀行員として伝えたい。日銀金融庁FP協会財務省エリートが作ったお金を学ぶサイトが超有益給与明細から投資保険クレカインフレやつみたてNISA仮想通貨まで。小学生から、わかったつもりの大人も。もちろん0円。各資料で… https://t.co/rZ6zflv5HK"

121あとで/1298users 安倍晋三元総理とは何者だったのだろうか(田中良紹) - 個人 - Yahoo!ニュース

121あとで/1241users 【ドドンッ!】有名YouTuberが使ってる『効果ラボ』の実態に迫る | ジモコロ | イーアイデム

116あとで/679users 正規表現先読み・後読み | USAMI Kosuke | Zenn


増田でもよく見かけた投資ネタエントリ多め。今月は増田からランクインは無し。

体のトレーニングストレッチエントリがちらほら。

2022-08-11

anond:20220811220258

クチンは「来週までにAWSEC2インスタンスVPC でつないで、グローバルIPをとって公開する方法勉強してきてね」「フロントエンド不要になったから、来週までにスプリング勉強してきてね」「なんか Python必要になるから勉強してきてね。だいたい Ruby とおんなじだから週末でいけるよね?」という感じだったな。

2022-03-11

AWS+Terraformを勉強中なんだがこういう流れで行こうと思ってるんだけどどう?

Apache(かnginx)+EC2+VPCの設定をとりあえず行ってWebサーバが動くところまで確認

PHP+RDS+EC2+VPC+ALBでもうちょっとリッチアプリ冗長構成で構築

上で作ったアプリDocker+ECSコンテナとして動かす

更に同じものECSじゃなくてEKSで動くように実装

こんな感じで考えてるんだけどどう思う?

2022-01-25

本のまとめ

--

この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。

1章

コンテナとは】

他のプロセスとは隔離された状態OS上にソフトウェアを実行する技術

コンテナ利用のメリット

環境依存から解放

コンテナにはアプリの稼働に必要となるランタイムライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリ依存関係をすべてコンテナ内で完結できる。

依存関係を含めたパッケージリリース単位となる

環境構築やテストに要する時間の削減

優れた再現性ポータビリティ

全ての依存関係コンテナ内で完結するため、オンプレでもクラウドでも起動する。

ステージング環境テスト済みのコンテナイメージプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテスト必要工数を削減できる。

リソース効率のアップ

サーバー仮想化では、仮想マシンレベルリソースを分離し、ゲストOS上でアプリが起動する。つまりアプリだけでなく、ゲストOSを動かすためのコンピューティングリソース必要

一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。

Dockerとは】

コンテナライフサイクル管理するプラットフォーム

アプリコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。

アプリソースコード + Dockerfile

↓ buildでイメージ作成

イメージ(アプリケーションと依存関係パッケージングされる。アプリライブラリOS)

shipイメージの保存

レジストリに保存

run コンテナの実行

オンプレクラウドなどで起動

Dockerfileとは】

イメージを構築するためのテキストファイル

このファイルコマンド記述することで、アプリ必要ライブラリインストールしたり、コンテナ上に環境変数を指定したりする。

1章まとめ、感想

コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンド設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。

2章

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 shiftOpenSearch 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までであること。

VPCIPアドレスの割当量に気をつける

ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能IPアドレスが消費されていく

スケールアウトによるIPアドレスの枯渇に注意

Application Autoscaling

Fargateで使用可能

Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う

ステップスケーリングポリシー

ステップを設けて制御する

CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意ステップに従ってタスク数を増減させる

ターゲット追跡スケーリングポリシーとは

指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針

ターゲット追跡スケーリングPermalink | 記事への反応(0) | 21:45

本のまとめ

--

この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。

1章

コンテナとは】

他のプロセスとは隔離された状態OS上にソフトウェアを実行する技術

コンテナ利用のメリット

環境依存から解放

コンテナにはアプリの稼働に必要となるランタイムライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリ依存関係をすべてコンテナ内で完結できる。

依存関係を含めたパッケージリリース単位となる

環境構築やテストに要する時間の削減

優れた再現性ポータビリティ

全ての依存関係コンテナ内で完結するため、オンプレでもクラウドでも起動する。

ステージング環境テスト済みのコンテナイメージプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテスト必要工数を削減できる。

リソース効率のアップ

サーバー仮想化では、仮想マシンレベルリソースを分離し、ゲストOS上でアプリが起動する。つまりアプリだけでなく、ゲストOSを動かすためのコンピューティングリソース必要

一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。

Dockerとは】

コンテナライフサイクル管理するプラットフォーム

アプリコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。

アプリソースコード + Dockerfile

↓ buildでイメージ作成

イメージ(アプリケーションと依存関係パッケージングされる。アプリライブラリOS)

shipイメージの保存

レジストリに保存

run コンテナの実行

オンプレクラウドなどで起動

Dockerfileとは】

イメージを構築するためのテキストファイル

このファイルコマンド記述することで、アプリ必要ライブラリインストールしたり、コンテナ上に環境変数を指定したりする。

1章まとめ、感想

コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンド設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。

2章

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 shiftOpenSearch 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までであること。

VPCIPアドレスの割当量に気をつける

ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能IPアドレスが消費されていく

スケールアウトによるIPアドレスの枯渇に注意

Application Autoscaling

Fargateで使用可能

Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う

ステップスケーリングポリシー

ステップを設けて制御する

CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意ステップに従ってタスク数を増減させる

ターゲット追跡スケーリングポリシーとは

指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針

ターゲット追跡スケーリングPermalink | 記事への反応(0) | 21:45

2021-02-18

サイトがはっきんぐされて なんか できないから もうおしまい

みたいなはなしなんだろうな

Wordpress よけいなことしかしないな

バージョンアップするな いまうごいているものに なにかするな

VPCぐらいかAmazonにはくるしめられつづけているけど

よけいなことをするな なにもするな そのまま同じ機能を同じママいじしつづけてくれ

 

まさに父親と同じ 家に金入れているんだからしかけるな かねの催促しか無いんだから

家族キャバ嬢ではない。

でも家にお金を入れている父親としては、そうおもうだろうね。

2021-01-29

http://ダミー.cloudfront.net/ 自閉したVPCからAPを経由して、動的な認証込みのEC2サーバコンテンツをどうやって、クラウドフロントから流し込むか

というののテストがようやく佳境 AWSは知っているプログラマーがやって1週間程度(調査期間)APめんどくさいが、ドキュメントのみで構築可能 サポートの人力対応不要でいけることを確認 インシデント使用0でなんとか自己解決できそうな見込みがたってきた

 

認証部分のスクリプトも同じサーバから流し込みたいので、Cloudfrontと自閉VPCとの組み合わせをさぐっていて、いろいろなパターンで、逃げもききやすい組み合わせを現在バージョンで調べるのがめんどう。

CloudfrontがS3には対応しているんだけど VPC対応してなくないか?AccessPointがみあたらない・・・ まぁそんなわけないから 探すけど

グローバルIPを一切もたないEC2(動的コンテンツ)にどうやってつなぐんだろう

できればそういう使い方をしているとか、しられたくないから、さぽせんに問い合わせたくない がんばる

 

安全破壊もそうだけど、基本的にまちがっちゃって、ってというのが可愛そうだから 故意でないと起きないように気をつけてるんだ偶然の排除に そのへんがサイト設計ノウハウからねやっぱり

2021-01-24

anond:20210124113829

2週間ぐらい前にlambda pressやって、先週ぐらいかlambda rdsに入っているけど またvpcトラブルが出ている 古い契約からかえていないのに、いつのまにかシングルAZになっていて、つながらなくてびっくりしたし

なんか、Amazon先生ですら混乱している感じ

anond:20210124104212

とはいえAWS lambda press とか lambda rdsとか この10年でいろいろ増えたから、ちょっと調査して、どうしようか、今調べている。

だけど、VPCはどう考えても設計ミスっている。

anond:20210124103122

いやいま検証している。

昔の設計VPC比較検討しているけれど、

どうかんがえてもVPC設計に不備があるようにしか見えない。同じことは古いAmazon仕様でもできるけど

はるか設計が優れている

文化されていないことが、あまりにもできなさすぎる

2021-01-23

Amazon RDSとVPCがなけりゃ しあわせだったなぁ

2020-05-29

lambdaとRDS

モバイルアプリを作っていて、API経由のDB接続をするために、

apigateway経由のlambdaからRDSに接続しようと考えた。

ひとまずLambdaからRDSへの接続を作ったのだが、

lambdaからRDSに接続ができないという現象が発生した。

lambdaVPCが設定されていなかった。

②RDSのVPClambdaVPCと一致していなかった

③RDSに設定したセキュリティグループインバウンド設定にあるセキュリティグループ

 lambdaセキュリティグループと一致していなかった。

なんやかんやしながらだけど、そのちょっとだけで1日かかった。

2020-05-23

EC21台 RDS1台の最小構成だけど ロードバランサー最初から入れておいたほうが楽かもね

ロードバランサー1台 EC2 1台 RDS1台 VPC2個 サブネット2個ぐらいかスタートするのがいいか

テストときだけEC2 2台にして 普段は1台で とまったらとまったでいい

2020-05-07

anond:20200507120921

マストドン構成を全部コンテナにして一つのVPCインスタンス運用するとめちゃくちゃ遅いのと一緒でつね(違う)

2020-04-22

境界防御意味ねぇの?

https://b.hatena.ne.jp/entry/s/www.itmedia.co.jp/news/articles/2004/21/news117.html

https://b.hatena.ne.jp/entry/s/www.ntt-east.co.jp/release/detail/20200421_01.html

まだ無理だろ、100%は。AmazonからVPC提供されている以上何らかの境界分離は必要から提供されてるんだろ。

https://koduki.hatenablog.com/entry/2020/03/02/131415

もちろんゼロトラストは進めばこんなにいいことないけど、ゲートウェイになり得るサーバサービス、仕組みそのもの統一できていなくて未熟じゃん。

SAMLとかクソめんどくさいの誰が使うんだ。俺は各サービスごとにSAML実装とかクソだるくて嫌だぞ。1つや2つ程度の小さなサービスしか運営していないイキリちゃんならいいよ。

でも世の中の金が回っている会社1020ではきかないほどにサービスなりページなり存在してネットワーク図書くと蜘蛛の巣みたいになるんだから現実的じゃないよ。

Cloud IAP?なんであんもの入れなきゃいけないの?

実装に手間がかかりすぎるんだよ。あんもの人情シスだったらどれだけ時間食うんだよ。

結果としてすぐにできるVPNが重宝されるし利用されるの。

2016-12-29

はてブで「Amazon」と検索してみると

昨今話題になってるヤマト佐川関連のブックマークが上位を占めるかと思いきや、まったく違った。

2016年12月29日10:54時点、本文、新着順で検索

Amazon検索結果 (絞り込み: 3 users 以上) 約 3,423 件中 1 - 40 件目 (0.26 秒)

以下略

ECサイト連想させるトピックほとんどなくて、AmazonB2B向けサービスを充実させていることに驚いた。

Amazonって表向きは物流業界革命問題を起こしている要因に挙げられているけど、EC以外のインパクトがどれだけ大きいのか門外漢なので分からない。

↑でブクマ付けた人、何が起きるのか教えて

2016-01-28

スタートアップに参加するモチベーション

スタートアップに身を置くのは色々な理由があるかと思う。

俺の周りは何か大きなことを言うのだが裏には"役職が欲しい"と言うゲスな考えの人間が多い。

あわよくばCXOのポジションに就けると思うらしい。

先日全く興味がないと思われる業種のスタートアップ入社して1年弱のやつと久々に会ったら何か奇妙な役職を名乗っていたので何この役職おいしいの?って聞いてみた。

まだCTOは名乗れ無いので(シリコンバレーかぶれの)社長提案で奇妙な横文字役職を貰ったとか話している顔が妙に嬉しそうで気持ち悪かった。

仕事内容を聞いてみると開発全般インフラも見てるとか話していたのだけど、お前インフラの知識なんてゼロだったけど大丈夫なのかなと思い使っているというAWSの話に持っていき結構基本的VPCとサブネットの話を振ってみたら固まった。

役職名乗る前に業務頑張れよ

2012-03-03

Amazon web serviceのセミナーに行ってきた

価格はもちろん、サービス豊富さ、開発スピードの速さ、日本の他のクラウドサービスで対抗できるところがどこにあるの?

というのが正直な感想

99.999999999%の可用性、世界中にあるリージョン、エッジロケーション

MapReduce、Sで始まるサービスVPCにDirect connect

そして、セミナー講師が背筋が寒くなるほどに優秀。

amazon死角がどこにあるのでしょうか。同業他社涙目です。素晴らしすぎました。

2009-03-08

http://anond.hatelabo.jp/20090307223244

なんでVPCLinuxが正しくインスコされねーのかな?ウブもフェドラも駄目ってどういう…

VPCは24bitカラーに対応していない

そこだけ注意しておけば大抵問題なく入れられる

http://anond.hatelabo.jp/20090307223244

>なんでVPCLinuxが正しくインスコされねーのかな?ウブもフェドラも駄目ってどういう…

VPC?VPCってVirtual PC?

なんで、VPC? VMWareでよくね?

可能性としては、

ドライバが入ってない

Netinst版を選択したが、仮想ネットワークドライバネット接続されてない。

あたりじゃね?VPCなんて、つかわねーから知らん。

ついでにHyper-Vも試したが・・・アレだったし。当面は、Widnwos系ならVMWare一択だとおもう。

VMwareが良いという事ではなく、選択肢が他にないという意味で。

2009-03-07

死亡遊戯 1回目

今日1日の行動

VPCLinuxインスコ→失敗

・2時半から車借りて知多半島ドライヴ

産業道路スカッと発散

VPCLinuxインスコ→失敗

なんでVPCLinuxが正しくインスコされねーのかな?ウブもフェドラも駄目ってどういう…

>2時半から車借りて知多半島ドライヴ

iPhone繋いでステレオだだ漏れとかいう超メイワク仕様知多半島クルージングレンジャー

海が見えてヒャッハー!とかなっちゃってもう大変だったわ。

産業道路スカッと発散

無料自動車専用道路では破格の時速70km/h制限の「産業道路」こと国道155・247号線を知多市朝倉付近から加家ICまで5000rpmぶん回して日頃のフラストレーションをドバッと発散させた。

風強かったからハンドル持って行かれそうになったしね。

 
ログイン ユーザー登録
ようこそ ゲスト さん