  |
はてなキーワード: EC2とは
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に１つのプロセスが稼働している扱いになる。
【Dockerとは】
アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。
イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)
レジストリに保存
【Dockerfileとは】
このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。
1章まとめ、感想
コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。
2章
ECSとEKSがある。
オーケストレーションサービスであり、コンテナの実行環境ではない。
ECSの月間稼働率は99.99%であることがSLA として保証。
デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・App Runner
利用者がコードをアップロードするだけでコードを実行できるサービス。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の登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策（不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス）を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloud watch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRed shift やOpenSearch Serviceにログを転送できる
fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
- 方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる（スキャン自体は1日1回のみ可能）
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloud watchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
cloud watch メトリクスなどで監視する必要がある。
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に１つのプロセスが稼働している扱いになる。
【Dockerとは】
アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。
イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)
レジストリに保存
【Dockerfileとは】
このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。
1章まとめ、感想
コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。
2章
ECSとEKSがある。
オーケストレーションサービスであり、コンテナの実行環境ではない。
ECSの月間稼働率は99.99%であることがSLA として保証。
デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・App Runner
利用者がコードをアップロードするだけでコードを実行できるサービス。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の登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策（不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス）を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloud watch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRed shift やOpenSearch Serviceにログを転送できる
fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
- 方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる（スキャン自体は1日1回のみ可能）
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloud watchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
cloud watch メトリクスなどで監視する必要がある。
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
[前回](https://anond.hatelabo.jp/20211221045059)
全員が経営陣と友達ということもあって、大学の仲が良い研究室とかサークルみたいなノリ
会社のwebページにはベタだけど、肩を組んで笑っている写真が載っていた
資金調達も上手くいっているようで、当時としては結構良い額の給料を貰えた
CEOはプロダクトも無いのに講演会とか取材に応じていて、界隈では少しだけ話題になっていたような気がする
自分には凄いキラキラして見えて「この会社はきっと有名になる！」って何の根拠もなく思ってたｗ
資金調達は順調に行えたが、プロダクト開発は順調とは言えない状態だった
まず仕様が決まらない(そもそもコンセプトからして無いのだから当たり前だがw）
そのくせ、CTOはやたら可用性や表示速度を気にしているようだった
自分はRailsとPHPのスキルしかないため、herokuとか、EC2に立てて様子を見ようと提案したが、
議題は目標が無いまま細かいシステム構成だったりフレームワークの選定に終始した
続き
驚いたわ。
新卒で就職してから、（敢えて分類するなら）Web系ベンチャー的な会社にずっと居たんだが、某大手SIerと提携してプロジェクト進めることになったんだわ。名前は出せないけど、みんな知ってるあの会社だよ。
こういう会社の評判はネット上でよく耳にするけど、それは誇張されたものだと思ってた。実際、そういう会社は社会的に成功してるんだし、社員も高学歴の人がほとんどなんだから、使っている技術が多少古臭くても、仕事のレベルは高いんだと思ってた。だが、そんなことは全然無かった。
うちの技術者が10分でできるようなことが、何回も会議をしたり、書類を埋めたり、向こうの上司の承認を得たりで、3ヶ月くらいかかる。そんだけ会議した後、やったのは、テンプレートからAWSのEC2インスタンスを起動していくつか必要な初期設定をしただけ。
言い忘れてたが、プロジェクトの内容はうちの製品を向こうの会社名義で売るということ（いわゆるOEMというのか？よく知らん）。
で、開発者向けのAPI等のドキュメントが既にWeb上に公開されてたんだが、なんか上司がはんこ押す書類と一緒にしなきゃいけないという理由で、これをエクセルに転記させられた。向こうの指定した方眼紙フォーマットにな。CSVなどに出力して一括でコピペすることさえできないストレスは想像を絶するものだった。エクセルにスクリーンショット貼り付ける作業で精神病むのも納得。
他にも意味の分からん制限が多かった。セキュリティポリシー的に、Google Drive等の外部サービスで情報を共有するのはNGだというんだが、上司がCCに入ったメールで送ったあとならOKらしい。んで、そういうメールを受信したらSlackに転載したりする馬鹿みたいなスクリプトをたくさん書いた。書き始めたらすぐに向こうの意味不明な運用に合わせたシュールでカオスなプログラムになった。もちろん、これも実際動かすには承認に何ヶ月もかかる。
こいつらの仕事の出来なさは、もうプログラミングができないとかそういう次元を超越してる。
当初のイメージでは、「使ってる技術が最先端ではないだけで、仕事の段取りとかはちゃんとしているのだろう」とか思ってたが、そんなことは全くなかった。
技術とか以前の問題。意味のあることと無いことの区別がついていない。「そういう段取りになっている」という理由でただ言われたことを作業的にやるだけ（まあ、一定レベルの知的労働を流れ作業に帰着させるのはある意味すごいとも言えるが）。
俺の関わった連中が例外的にひどかったと思いたいが、まあ、現実問題そういうことはないのだろう。
俺の大学の同級生も、NとかFとかNとかHとかの付くSIerに就職していったが（上記の会社はその1つである）、こういう仕事をしているなら完全に人材の無駄遣いだと思う。コンビニパートのおばちゃんとかで変わり利くもん。
これからエンジニアとしてキャリアを築きたい学生とかは、絶対にこんな会社に入っちゃいけない。まともなスキルは全く身に付かないぞ。
年収270万の元増田です。2013年のフロントエンド界隈にいた（jQuery と Adobe Flash）のですけど、今って本当に700万近くまでもらえるのですか？例えば、React や Vue を TypeScript でかけたりするとどれぐらいもらえるのでしょうか。
自分は 2013年ぐらいに Java で Android と iPhone にて Objective-C で、jQuery でブラウザのフロントエンド部を書いていたら、強制的に Spring Framework で SQL バリバリのバックエンドを書くように指示されて、しかも AWS EC2 の上でプロダクション用の構成をつくったりしてたのですけど、２社目の社長に「職歴が浅いから、月給25万円ね」と言われて、絶望した記憶があります。
MSは元々ソフト屋だからWindows ServerとかSQL ServerとかActive Directoryとかをマネージドで出したり、GoogleもSpanner作ったり、Firebase出したり（買収だけど）、Tensorflow統合出したりKubernetes統合出したり（どっちもパクられてるけど元はGoogle産）してるけど、
AWSはどちらかというと本当にハード貸し（AWSが作った最大のソフトウェアは「サービスとしてのハード貸し」を発明したEC2とS3とは言えるかもしれない）というイメージ
VPSとの違いはやっぱりEC2とS3で、需要に応じて自動でスケーリング可能な「サービスとしてのハード貸し」を実現したからだと思う
それは確かにソフトウェアで実現されているけれど、肝になるのは「顧客のピーク需要に常に応えられるほどの余裕を持ったインフラ」というハードウェア投資かなあと思う
| 時間 | 記事数 | 文字数 | 文字数平均 | 文字数中央値 |
|---|---|---|---|---|
| 00 | 115 | 10115 | 88.0 | 44 |
| 01 | 54 | 4957 | 91.8 | 36.5 |
| 02 | 95 | 13194 | 138.9 | 43 |
| 03 | 75 | 4636 | 61.8 | 34 |
| 04 | 29 | 1709 | 58.9 | 30 |
| 05 | 31 | 2037 | 65.7 | 45 |
| 06 | 19 | 1374 | 72.3 | 67 |
| 07 | 44 | 3412 | 77.5 | 55.5 |
| 08 | 99 | 10688 | 108.0 | 46 |
| 09 | 187 | 14616 | 78.2 | 42 |
| 10 | 144 | 8688 | 60.3 | 30 |
| 11 | 167 | 13793 | 82.6 | 46 |
| 12 | 166 | 12962 | 78.1 | 38 |
| 13 | 113 | 10292 | 91.1 | 54 |
| 14 | 102 | 11566 | 113.4 | 54 |
| 15 | 160 | 13637 | 85.2 | 37.5 |
| 16 | 99 | 11918 | 120.4 | 31 |
| 17 | 114 | 9614 | 84.3 | 38.5 |
| 18 | 158 | 16535 | 104.7 | 49 |
| 19 | 217 | 16412 | 75.6 | 39 |
| 20 | 156 | 17199 | 110.3 | 47.5 |
| 21 | 191 | 17627 | 92.3 | 39 |
| 22 | 142 | 10071 | 70.9 | 34.5 |
| 23 | 211 | 13731 | 65.1 | 37 |
| 1日 | 2888 | 250783 | 86.8 | 40 |
SMBC(22), カレピッピ(5), ラッカー(6), 多重派遣(3), 扶養照会(5), 性染色体(3), Clubhouse(5), １０億(7), ボストロール(3), 多重請負(3), EC2(3), 流出(31), 300万(23), 生活保護(48), エヴァ(10), 一文(7), コード(33), やりがい(7), プログラマー(31), 西野(6), BGM(7), 銀行(15), ファクトチェック(8), 汚染(7), watch(16), 未成年(9), 父親(30), 髪の毛(7), 読者(16), 出産(25), IT(26), 障害者(13), 主人公(32)
■みんなの好きなゲームの曲を聴きたい /20210128222744(62), ■日本のITのレベルは低く、向上がほとんどない /20210129090723(21), ■鬼滅やエヴァの主人公が子どもでなければならない理由 /20210128210453(19), ■巨大な壁が出てくる作品 /20210115125713(19), ■ /20210129011602(16), ■暖房機器がない部屋で生き残るには？ /20210129220038(12), ■はてな世論における「社会が悪い」「本人が悪い」の線引きがわからん /20210129111142(12), ■理由を教えてくれないとモヤる /20210129183904(11), ■ごぼういっぱい貰った /20210128222326(9), ■油揚を焼いて食った /20210128232047(9), ■トイレで一人で出産するJKの生命力すごすぎる /20210128183921(8), ■いくら寿司食べたい /20210128231620(8), ■SMBCコード流出の何がやばいのかわからない /20210129121224(8), ■最終的には生活保護って発言に、なんであんなにキレてるの？ /20210129153724(8), ■息苦しい日本 /20210129182440(8), ■なんで毒親毒親言ってる人に女性が多いのか？ /20210127085735(7), ■叩かれても叩き返したら同レベルになる説ってどうなん？ /20210129154616(7), ■キャリア20年以上で年収300万の人間って /20210129083102(7), ■絶対に座右の銘にしてはいけない言葉 /20210128002749(7), ■段落って知ってる？ /20210129150612(6), ■「2位じゃダメなんですか」の真実 /20210129203651(6), ■生保増えるのまずくね？ /20210129201607(6), ■俺もキャンプ始めようと思った過去あるけど納得いかない、腹立つクソな点が多すぎた /20210128133901(6), ■anond：20210128183921 /20210129110827(6), ■anond：20210129191511 /20210129191806(6), ■トマトの正しい発音はトゥメイトウ /20210129123427(6), ■29歳になってしまったんやが /20210129125346(6), ■再婚のために婚活アプリに登録したのだが /20210129141315(6)
http://ダミー.cloudfront.net/ 自閉したVPCからAPを経由して、動的な認証込みのEC2サーバコンテンツをどうやって、クラウドフロントから流し込むか
というののテストがようやく佳境 AWSは知っているプログラマーがやって１週間程度（調査期間）APめんどくさいが、ドキュメントのみで構築可能 サポートの人力対応不要でいけることを確認 インシデント使用０でなんとか自己解決できそうな見込みがたってきた
認証部分のスクリプトも同じサーバから流し込みたいので、Cloudfrontと自閉VPCとの組み合わせをさぐっていて、いろいろなパターンで、逃げもききやすい組み合わせを現在のバージョンで調べるのがめんどう。
S3 press をつかわずに wordpressをec2で上げてるから、クローラーが来ると重すぎて、動かなくなるから
どう考えても、クローラーは広告読まないどころか、広告消して、おいしい記事だけ利用するからな
でも、お金がなければs3
負荷分散とか、いろいろ１２年近く勉強になった。いろんなことがあった。
でも１円にもならなかったなぁ。１円ぐらいにはなってるかｗｗｗ
