  |
はてなキーワード:Cloudfrontとは
問題 1
あなたはある企業のAWSアーキテクトです。既存のオンプレミスの金融データをAWSに移行する必要があります。移行後、すべてのデータは 削除や上書きができないように保護 する必要があります。
A.AWS StorageGateway +AmazonEBS +Object Lock
B.AWS DataSync +Amazon S3 +Object Lock
C.AWS DataSync +Amazon EFS +Object Lock
D.AWS StorageGateway +Amazon S3 +Object Lock
回答C。 AWS StorageGateway は名称てきにオンプレミスと sync しなさそうだから、DataSync -> EFS だと考えた。S3はストレージだからなし。
問題 2
Auto ScalingグループにあるEC2インスタンスのスケールインが発生しました。
デフォルトのスケールインポリシーの場合、どのインスタンスが優先的に削除されますか？（3つ選択）
C. 最も最近作成されたLaunch Templateのインスタンス
D. 最も古いLaunch Templateのインスタンス
スケールイン,スケールアウトの違いがわからない。アウトは拡大する、インはスケール縮小？
回答：A, 多いほうから削る。D, 古いものは削除、E,残り時間が少ない順から削る？
問題 3
グローバルに展開するアプリケーションがあり、ログイン処理が遅く、HTTP 504エラーも発生しています。
CloudFrontを利用してコストを抑えつつ、パフォーマンスを改善する方法として適切な組み合わせはどれですか？（2つ選択）
A.複数リージョンにアプリを展開してRoute 53のレイテンシルーティングを利用
B.CloudFrontのオリジンにCache-Controlmax-ageを設定してキャッシュ比率を上げる
C.Lambda@Edgeを使って認証処理をユーザーに近い場所で実行
D. 各リージョンに複数VPCを作りTransitVPCで接続してSAMでLambdaを配置
E.CloudFrontのオリジングループでフェイルオーバーを設定
回答：BとCかな。Aは手数が多すぎる。非効率かなと。Dも工数がかかりそう。手作業で複数作るのかな？Eはこういう設定して意味あるのかなと思った。
問題 4
医療系企業がAWSで複数のアプリケーションVPCを作成します。各アプリは 共有サービスVPC にアクセスする必要があり、アプリ同士も通信します。
将来的に数十のアプリが追加されることを考慮した場合、管理負荷を最小化する構成はどれですか？
回答：A 他はなんか怪しい。
問題 5
アプリケーションはEC2 + RDSSQL Server で構成されています。
要件:EC2とRDS間の通信はすべて暗号化されていなければならない
どの設定が最適ですか？（2つ選択）
A.EC2とRDSのセキュリティグループでポート443のみ許可
C. rds.force_sslパラメータをtrueにしてDB再起動
E. RDSルートCA証明書を取得しアプリでSSL接続を設定
回答 AとC。Eも正解っぽく感じる。
ーーーーー
答え
ーーーーー
問題 1
あなたの回答：C (AWS DataSync +Amazon EFS +Object Lock)
実際の正解は B (AWS DataSync +Amazon S3 +Object Lock)
理由：
Object Lock はAmazon S3 のみ がサポートしています。EFSやEBSではできません。
AWS DataSync で S3 にデータを移行し、Object Lock を有効にすると、削除や上書きを防止できます。
StorageGateway はハイブリッド用途（オンプレと同期）に便利ですが、このシナリオではすべてクラウドに移行するため不要です。
問題 2
あなたの回答：A, D, E
正解：A, D, E ✅
理由：
スケールインは 余剰リソースを減らす操作（インスタンスを削除する）
選ばれたAZの中で 最も古いLaunch Templateのインスタンス を削除
※「スケールイン＝縮小」「スケールアウト＝拡大」で覚えておきましょう。
問題 3
あなたの回答：BとC
正解は C と E
理由：
Lambda@Edge →認証処理をユーザーに近い場所で実行でき、ログイン処理を高速化
B（Cache-Controlmax-age）は静的コンテンツのキャッシュ用で、このシナリオの問題（認証処理の遅延や504）には直接関係なし
AやDはコストや運用負荷が高く、今回は「コストを抑えて改善」が条件
問題 4
あなたの回答：A
理由：
VPC Peering は数が増えると接続管理が爆発的に複雑 になる
TransitGateway を使えば 1つの中央ハブ で全VPCを接続でき、管理負荷が大幅に削減
VPNやDirectConnectはオンプレ接続用なので不適切
問題 5
あなたの回答：AとC
正解は C と E
理由：
rds.force_ssl=true → RDSがSSL接続を強制
クライアント側で RDSルートCA証明書を使用 してSSL接続
TDEは 静止データの暗号化 用で、通信の暗号化には関係なし
Cloudflare が海賊版運営サイトについて停止するようにと訴訟が起きてるんだってな。
詳しいことはわざわざ調べて無いが海賊版とインターネットについてちょっと思うことがあったんで垂れ流してスッキリしようと思う。
ISP と契約してインターネットを使えるようになるし、サイトを作りたい人間は自分のサーバーでも借りたサーバーでもホームページを構えることができる。
それで海賊版サイトを作った人が現れてもISP は滅多に訴えられない。 すぐに責任を取るべき人に責任を取らせられるからで、今回では身元を隠したままサイトを運営している人に対してどうやって責任を取らせるのか。
そんなところでCloudflare が訴えられたんじゃないかなと記事をちらっと読んで感じたのが今さっき、『もう話題にするのおせーよ（笑）』ってのはナシで。
それで結局何を感じて何をこれから書こうとしているのかと言えば、作品の価値の感じ方を変えるべきなんじゃないかというある種の諦念を吐き散らして行こうと思っている。
インターネットがない頃、普及してない頃にもコピー機というのは存在していて、漫画も写真も複製出来て精度は悪いだろうがやろうと思えば出来たことで、当然それを流布すれば然るべき所に送られるだろう。
現実に目に見えるものだから今まで対策が出来たのではないか、対策が出来てなかろうと対処は出来ていたのではないか。
そういうのは当たり前に誰もが思ってる事かもしれないが、インターネット上で似たことをする輩のせいで不利益を被っているのが現状だと理解している。
今回では、母数が増えまくった事によってどうにも対処が出来なくなってしまったのでCloudflare へ矛先が向いたのだろう。
ああいう類のサイトがCloudfront を利用していたらAmazon が訴訟されていただろうと思う。
こういうのはモグラ叩きのように事が発生次第対処しなければならないが、CDN などの基盤側がいちいちサイトの内容を確認する責任はないと思われていたのがこれまでの価値観だったと思う。
ただ、そのためのリソースを割くのは創作を行う側も、ただweb ページの負担を軽減させるサービスも大変だろう。
さて本題で、こういった問題について考え方を改める事で対抗出来ないかと妄想しているのが今回の文章だ。
作品そのものではなく、作品を所有することを制作者から認められている事について有難がる事で、海賊版の価値を無いものに出来ないかと思い浮かぶ。
『あの人が好きだからあの人の作品が好き』『この作品が好きだから作り手も尊敬する』というのは普遍的な感情で、ポジティブなベクトルなら素敵な心持ちにもなる。
坊主憎けりゃ袈裟まで憎しを避けるなら、作品そのものを提供する側から見たい作品を見せてもらっている事について有難がると良いだろう。
物質への感情の矛先を正当な仲介者へ向ける事で間接的に作品へ感情を向けつつ、不当な流布の価値を限りなく下げられる。
そうすればその価値観の枠組みの中でなら正当な仲介者以外が流布する作品は無意味となり、立派な対抗になり得るだろう。
これを強制させる枠組みを考えるなら、その権利を買えるようにすることにあると思う。 ただ、消費者も権利を買っているという認識をしなければ無意味だ。
そういったものをシステム化するなら NFT のような所有権を分散ネットワークに記録できるものが流用出来ると考えている。
そもそも NFT は『作品そのものではなく所有権をやり取りしている』のだから無意味とされてきた代物だ。
The request could not be satisfied.
We can'tconnect to the server for this app orwebsiteat this time. There might be too much traffic or a configurationerror.Tryagain later, or contact the app orwebsite owner.
Ifyou provide content to customers throughCloudFront,you can find steps to troubleshoot and help prevent thiserrorby reviewing theCloudFront documentation.
The request could not be satisfied.
We can'tconnect to the server for this app orwebsiteat this time. There might be too much traffic or a configurationerror.Tryagain later, or contact the app orwebsite owner.
Ifyou provide content to customers throughCloudFront,you can find steps to troubleshoot and help prevent thiserrorby reviewing theCloudFront documentation.
Generatedbycloudfront (CloudFront) HTTP3 Server
RequestID: gpTV5kJbc7xesPlmWxthzeKZ6L9GlhdcTEstGmHhLQc1hfRD8pPXBA==
CloudFront attempted to establish aconnectionwith theorigin, but either the attempt failed orthe origin closed theconnection. We can'tconnect to the server for this app orwebsiteat this time. There might be too much traffic or a configurationerror.Tryagain later, or contact the app orwebsite owner.
Ifyou provide content to customers throughCloudFront,you can find steps to troubleshoot and help prevent thiserrorby reviewing theCloudFront documentation.
このページの上にあるテキストボックスだけどさ、何を入力しても以下のエラーが返ってくるんだけど、検索機能ってまともに動作してるの？
504ERROR
The request could not be satisfied.
CloudFront attempted to establish aconnectionwith theorigin, but either the attempt failed orthe origin closed theconnection. We can'tconnect to the server for this app orwebsiteat this time. There might be too much traffic or a configurationerror.Tryagain later, or contact the app orwebsite owner.
Ifyou provide content to customers throughCloudFront,you can find steps to troubleshoot and help prevent thiserrorby reviewing theCloudFront documentation.
504ERROR
The request could not be satisfied.CloudFront attempted to establish aconnectionwith theorigin, but either the attempt failed orthe origin closed theconnection. We can'tconnect to the server for this app orwebsiteat this time. There might be too much traffic or a configurationerror.Tryagain later, or contact the app orwebsite owner.
Ifyou provide content to customers throughCloudFront,you can find steps to troubleshoot and help prevent thiserrorby reviewing theCloudFront documentation.
なんか増田重くね？
PC版トップページ(https://anond.hatelabo.jp/ )の上部にある検索機能ってみんな使える？
なに検索してもCloudFrontのエラーページが出てくるんだけど俺だけ？
=====
504ERROR
The request could not be satisfied.
CloudFront attempted to establish aconnectionwith theorigin, but either the attempt failed orthe origin closed theconnection. We can'tconnect to the server for this app orwebsiteat this time. There might be too much traffic or a configurationerror.Tryagain later, or contact the app orwebsite owner.
Ifyou provide content to customers throughCloudFront,you can find steps to troubleshoot and help prevent thiserrorby reviewing theCloudFront documentation.
Generatedbycloudfront (CloudFront)
RequestID: ____
そもそもオンプレミスのシステムをクラウドに載せ替えてコストダウンできるという発想が間抜けだ。頭が悪い。クラウドはオンプレミスよりも高コストだと、ガートナーすら指摘している。クラウドにするのであれば、クラウドに適応したシステムに再構築すべきだ。例えば、静的ファイルは S3 +Cloudfront にして配信サーバーを少なくするとか、アプリケーションサーバーは需要に応じてインスタンスをスケールするようにして省力化するとか、データベースサーバーをAurora か RDS にしてバックアップの手間暇をなくしたりするとか、でもしないとクラウド化で高コスト化しちゃうよ。
・環境構築したくない。
・環境構築したら一応手順書残すじゃん。覚えておきたくないから。書くよね。めんどい。
・Ansible とかもめんどい (これは使ったことがないので学習がめんどくさいってだけ)。
・Python だの何だのの依存関係でバージョンがあわなくて…みたいなトラブル大嫌い (DockerならいいけどECS・Fargate・CloudRun・GKE それはそれで高いし、現時点ではメンテフリーとはいかない)
・Let's E とかもめんどい。だってたまにやり方が変わるじゃん。めんどい。
なのでPaaS にしたいのよ。
GCP で独自ドメインマネージドSSL するには Cloud Load Balancing必要でしかもそこそこ高いってのは想定外だったので、別にそこに金をかけるべきとは言ってない。でも月2000円くらいだからまぁいいやって感じ。もちろん月300円で済むようになればうれしい。
AWS は S3+CloudFront+ACM+Route53 で安く独自ドメインマネージドSSLができるんだっけ? であればそっちの方がいいよね。
＝＝＝＝＝
東大卒のヨーロッパでエンジニアやっている人から解説しよう。（ちなみに医学部は防衛医大に補欠合格していた）
エンジニアになるより医者やっていたほうが（国内で頑張る分には）絶対いいと思う
ちなみに医学部にいった友人の何人がむしろテック系に流れてきているという事情がある。
おそらく、増田はたしかに昔からプログラミングをやっていたと思う。頭もいいんだろう。厨ニが溢れていて気持ちが悪い。
エンジニアも厨ニ病でマウント取っていいていい時代でもないです。明らかにマウント取りたくてウズウズしすぎて、大した知識がないのに、
表面的な知識を羅列しているところがあったので突っ込んでいく。
ー＞そんなことない。フロントも色々やらないといけないが、バックエンドに比べて経験年数がひくい人も流れ込んできているので、バックエンドの人に比べて
できる領域が狭いので給与が低い、またおそらくDCL、DML、DDLといった用語を知っていることをひけらかしたかったのかもしれないが、全くどうでもいいです。
＝＞全部できようとして、破綻しているのでブーメランですよ。あなたの想定している、こんなフルスタックは成り立たない。
現場に放り込まれても１０年ぐらいかかる。というより、フロントからバックから低レイヤから、モバイルまでやることはもはや現実的ではない。
＝＞QUICとかマイナーなプロトコルを話すよりはちょっと変化球のあるプロトコルでいけばWebsocketぐらに抑えておきましょう。低レイヤーの話はわたしもわかりませんが、C言語ができないのに「おそらく QUIC か MQTT 」とか分かってない英単語４文字を羅列するのは厨ニ病すぎます。
=>自分はcloudfrontやWafを触ったことがありますが、かなりのインフラエンジニアにならないかぎり、ここ触りません。cdnは影響範囲が大きいし設定に時間が掛かったりします。片手間でできません。インフラエンジニアに触らせます。異常検知、アラートといったものは、実は結構時間がかかるので、強いかどうかではなく責務の分割からインフラに任せます。知らないことは知らないって書きましょう
本当に医学生ならここ数年の技術についてこの指摘ができる程詳しいわけないし少なくとも10年位は業界にいないとこういう感覚は身に付かない。 」
＝＞こんなにあれこれ、やっている時間はないでしょう。趣味のサイト製作でやるにしても絶対できてない。kubernetesを使っただけで時間切れになる。Kafkaを触ったとかいているが、Kafkaはサーバで使ったのかな？どういう利用シーンかというと膨大なログの収集等で使うのだが（ただのNoSQLではない）、Zookkeeperで調停させて、topic数とか調整するんだけど、わかってます？ElasticSearchだけ書いてたらまぁあるかなと思うけど。Redisもちゃんと使えてる？pub/subとか分かってないと思う（普通に理解する必要があんまない）
それでkotlinなんて触ってる時間なんて絶対にないし、Rustを更に付け焼き刃に付け焼き刃している時間なんてぜええええたいにない。やることが絞り込めてない。無意味にマウント取りたいだけ。なんとなく書いているcode deployなんて、それだけで使いこなすのが大変なれべる。
ci/cdのうちciだけかたっているならわかるがcdとなるとかなり時間がかかる
＝＞MyISAM をInnoDBに切り替えるなんてことしているところは無い。万にひとつあったとしても、大事で、それだけで数ヶ月のものなので、この付け焼き刃の知識の人が触る機会はない。
＝＞ES2015以降の差分は微々たるもので、どうでもいいです。ES2018ぐらいの現実的な数字にしてたらばれなかったのにね。
Next でSSRまで踏み込むと結構、フロントのことをキャッチアップするだけでかなり厳しいと思いますが、できているのかな？
＝＝＝＝＝
ー＞アメリカの事情は知らないはずなので知らないことは書かないようにしましょう。
ー＞ヨーロッパでは白人様はHRとかマーケやってます。移民にたよってます。ロシア、ウクライナ、インド、パキスタンなど
なぜ、ヨーロッパ人が避けるかといと「やる気がないから」です。以上
数あるCDN のなかでも Fastly は圧倒的に優れた特性を持つものだと思うので、障害にかこつけてその優れた点を紹介していく。
CDN とは世界各地にあるキャッシュサーバーにコンテンツをキャッシュして配信してもらうことで、オリジンサーバーの負荷を軽減したりユーザーへの配信速度を上げたりするリバースプロキシのホスティングサービスだが、 Fastly の最大の特徴としてはそのキャッシュが消えるのが速い。普通のCDN が数十秒〜数分とかかるのにたいして 0.2 秒で全部消えることが保証されているし、キャッシュにたいしてキーをつけておけば(HTTP ヘッダーに Surrogate-Key って入れるだけ)特定のキーがついているキャッシュだけ 0.2 秒以内に消したりということができる。
これにより、CDN による配信高速化の恩恵を受けながら、コンテンツをリアルタイムに更新していくことができる。next.js + vercel などはこのあたりをフロントエンドからCDN まで一気通貫に提供することでリアルタイム風にコンテンツを更新できるように見せかけているが、 Fastly なら本当になにもかもリアルタイムで出来ることが保証されるので、難しいことを考えなくてもよい。
CDN の設定の反映の遅さというのはCloudfront とか使っていれば感じることだと思うが、 Fastly なら 5 秒ぐらいで反映される。設定を変更しながらいろいろ検証しているときにこれが地味に嬉しい。
ただし上記の特性の代償と言えるのかもしれないが(そうではないのかもしれないけど)、 Fastly は「デカめの配信拠点を比較的少数配置する」という構成になっているため、ディザスタリカバリなどの面では不安がある(今回の障害はマジで全部落ちたのでこれとは関係ない問題だろう)。
Web 設定画面からいじれる設定項目が多く、にもかかわらずユーザーに優しく使いやすい。例えばリクエストヘッダーを Fastly 側で書き換えてもらう機能があるのだが、それとは別に Host ヘッダーのオーバーライドの設定は(えてしてよく使うので)別の画面に切り出されていたりする。
大抵のユーザーはWebからの設定画面でできることで満足すると思うが、高度な制御をしたい場合、 Varnish の設定ファイルのスニペットをアップロードしたり、あるいは設定全体を書いてアップロードする、といったことができる。例えば JWT のデコードをVCL でやってしまって、同じURI にたいして認証済みユーザーとそうじゃない人でキャッシュのだしわけなんてことが Fastly 上でできるようになる。
ただしVCL でいろいろな制御を実現しようと思うと、VCL の表現力の低さにより地獄を見ることになるので、得られるベネフィットと相談しながらこのあたりはやっていくことになる。
| 時間 | 記事数 | 文字数 | 文字数平均 | 文字数中央値 |
|---|---|---|---|---|
| 00 | 63 | 23322 | 370.2 | 61 |
| 01 | 59 | 8249 | 139.8 | 41 |
| 02 | 70 | 4566 | 65.2 | 31 |
| 03 | 21 | 1619 | 77.1 | 34 |
| 04 | 19 | 1917 | 100.9 | 50 |
| 05 | 24 | 3572 | 148.8 | 55.5 |
| 06 | 22 | 4097 | 186.2 | 67.5 |
| 07 | 35 | 3143 | 89.8 | 50 |
| 08 | 80 | 8965 | 112.1 | 38 |
| 09 | 150 | 8594 | 57.3 | 40 |
| 10 | 162 | 12498 | 77.1 | 41.5 |
| 11 | 175 | 18753 | 107.2 | 33 |
| 12 | 136 | 11913 | 87.6 | 36 |
| 13 | 139 | 15540 | 111.8 | 53 |
| 14 | 221 | 16909 | 76.5 | 44 |
| 15 | 164 | 12374 | 75.5 | 45 |
| 16 | 229 | 16790 | 73.3 | 43 |
| 17 | 116 | 20026 | 172.6 | 60.5 |
| 18 | 182 | 13387 | 73.6 | 34.5 |
| 19 | 139 | 16608 | 119.5 | 47 |
| 20 | 136 | 14632 | 107.6 | 31 |
| 21 | 173 | 13803 | 79.8 | 27 |
| 22 | 107 | 14030 | 131.1 | 68 |
| 23 | 175 | 17239 | 98.5 | 45 |
| 1日 | 2797 | 282546 | 101.0 | 42 |
トッド(6),手袋を買いに(4),CloudFront(3), 同伴者(3),橋本聖子(11),同人ショップ(3),蛋白(4),新美南吉(3),桜餅(5), 花江(3), ああああああああああああああああああああ(5),弱者男性(23),楽天(26), 通院(14),精神疾患(12),夫婦別姓(15), 別姓(9),心療内科(9),鬱病(10),ライト(12), 捕まえ(12),精神科(14),天皇(18),トマト(10), 姓(10),賃貸(12), 振ら(10),糖質(11),バイデン(15),メンヘラ(25),ジェンダー(15),モテる(14),声優(15),ワクチン(20),マンション(13),信者(12),容姿(20), 既婚(11),障害者(12)
■【追記あり】精神疾患の男性はだいたい一人で精神科に来る /20210218011829(26), ■ごんぎつね /20210217194952(13), ■アラサー腐女子だけどいつの間にかツイフェミになってたから絶望した /20210218193205(13), ■はてな好きな高校生なら知っておきたい100人のはてなー /20210217201733(11), ■「バイデンが井戸に毒を入れた」の差別対象はバイデンまたは日本人 /20210217173707(11), ■独身男性が赤羽や北千住に住むのは差別だ /20210218024210(10), ■トマトを上手に育てられない /20210217092500(9), ■服がわからんオタクへ /20210218183322(9), ■男オタクは臭く、太り、服がダサい /20210218144631(9), ■一番盛り上がりやすいんだろうけど /20210217105311(8), ■ある童貞の叫び /20210218191204(7), ■去年称賛された人たちのここ数日の動向 /20210218161601(7), ■ /20210218015913(7), ■孤独は寂しいな /20210217213600(7), ■声優がバラエティ出てキャラセリフ言ってるの見ると寒気がする /20210218092527(6), ■フェミは遊廓を性奴隷制度って言うけどさ /20210218020228(6), ■イラク戦争をテーマにした映画はなぜつまらないのか /20210218180326(5), ■もしコロナワクチンでネトウヨ脳に書き換えられるなら /20210218201742(5), ■好きじゃない女性に好かれた /20210216150213(5), ■天皇って皇帝なん？ /20210218203400(5), ■完全に理解した彼くん /20210217195635(5), ■低気圧ガー低気圧ガーうるせーんだよ /20210217213552(5), ■「40歳で特別なスキルのない主婦・・・」の記事読んだ /20210218013952(5), ■パトレイバー２に第二小隊を殺された /20210218062316(5), ■anond：20210218090427 /20210218090745(5), ■ /20210218100041(5), ■クレイジー /20210218104850(5), ■精神的病に冒されている人は治す気あるのかなあ。 /20210218110438(5), ■夫婦別性ってどうしてそうしたいの？ /20210218150658(5), ■男性に対するセクハラは容認されるという人権後進国 /20210218152350(5), ■ソフトバンクのLINEMO /20210218155153(5), ■彼氏にかわいいって言ったらキレられた /20210218163359(5), ■anond：20210218011829 /20210218165151(5), ■日本スゴイ病の感染源は天皇だよね /20210218173003(5), ■1年半ずっとATMとして働き続けたときの話 /20210218173806(5)
wp-login.php: $url = dirname( set_url_scheme( 'http://' . $_SERVER['HTTP_HOST'] . $_SERVER['PHP_SELF'] ) );
これだね PHPのほうにPDO入れてPHP側で捻じ曲げないとだめなんだろうな スクリプトから書き換えると ハッキングされるもんな CloudEdgeでPDOさがせばあるかな
アドミン：$_SERVER['HTTP_HOST']をPHPスクリプトで書き換えればいい
C++プログラマ PDOからPHPレベルで$_SERVER['HTTP_HOST']をCloudFrontように書き換える
http://ダミー.cloudfront.net/ 自閉したVPCからAPを経由して、動的な認証込みのEC2サーバコンテンツをどうやって、クラウドフロントから流し込むか
というののテストがようやく佳境 AWSは知っているプログラマーがやって１週間程度（調査期間）APめんどくさいが、ドキュメントのみで構築可能 サポートの人力対応不要でいけることを確認 インシデント使用０でなんとか自己解決できそうな見込みがたってきた
認証部分のスクリプトも同じサーバから流し込みたいので、Cloudfrontと自閉VPCとの組み合わせをさぐっていて、いろいろなパターンで、逃げもききやすい組み合わせを現在のバージョンで調べるのがめんどう。
