「Lambda」を含む日記 RSS

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

2022-05-15

ロシア語アルファベット英語アルファベット

英語アルファベットから誤って推測される文字
В, в

bではなくv

Ж, ж

xではなくzh

З, з

eではなくz

英語筆記体のzに似ている?

И, и

nではなくi

Й, й

nではなくy

Н, н

hではなくn

Р, р

pではなくr

ギリシア文字のΡ (rho)

С, с

cではなくs

У, у

yではなくu

Ц, ц

yではなくts

Ч, ч

yではなくch

Ш, ш

wではなくsh

Щ, щ

wではなくshch

Ъ, ъ

bではなく硬音符

Ы, ы

blではなくy

Ь, ь

bではなく軟音符

Ю, ю

loではなくyu

Я, я

rではなくya

英語アルファベットから推測しにくい文字
Г, г

ギリシア文字のΓ (gamma)

Д, д

ギリシア文字の⊿ (delta)

言われてみればDに似ている?

Л, л

ギリシア文字のΛ (lambda)

П, п

ギリシア文字のΠ (pi)

Ф, ф

ギリシア文字のΦ (phi)

2022-05-14

Railsが死んだのはわかった。では何使えばいい?

現代Webアプリケーションフロントエンドが中心で

バックエンドJSON返すだけの存在になったのはわかった。

からRailsやLaravelみたいなフルスタックフレームワークが捨てられてるのもわかった。

では何使えばいいのかよくわからん

Firebase? AWS Lambda?

Go流行ってるらしいけどGoEchoってやつを使えばいいのか?

2022-05-05

anond:20220504211823

★★再追記

レンタルサーバは、自由度が低くてストレスになるからやらない。SQLでwith使いたいかMySQL8をって言ってもさくらレンタルサーバじゃ無理なんでしょ? あと同居利用者のせいで高負荷ってのも避けたい。そこを気にしない人はレンタルサーバでいいと思うよ。

あと LB $0.025/h だった。月2000円くらいか

追記

LBは独自ドメイン+自動更新無料SSL証明書のためね。Cloud Storageの無味乾燥ドメインでいいなら、SSL自動かつ無料でほんとに月数円。

-------

もうねめんどくさいんだわ。もちろん以前はそうやってたよ。

PHPだのApacheだのMySQLだのインストールしたり設定ファイル置いたり、

脆弱性対応したり、SSL証明書更新したり、一応落ちてないか無料監視サービス使ったり。

でも仕事ならともかく、趣味からこそこんなことやりたくないじゃん。

なので、コンテンツは Cloud Storage に置く。

Cloud Load Balancing も使う (無料 SSL 証明書のために)。

認証必要なところは Cloud Identity で。

動的部分は Cloud Functions で。

AWS なら S3+ALB+Cognito+Lambda だな。

そうしておけば、放置できる。自前で立てたマシンインスタンスもないから落ちてるかどうかとか気にしなくてもいい。負荷も考えない。クラウド様がよきにはからってくれるさ。たまにクラウド障害あるかもしれないけど、Google なり AWS なりが頑張って直してくれる。

って感じ。

ちなみにこちらは 1日数十アクセスの過疎サイト独自ドメイン+自動SSL証明書にするための Cloud Load Balancing に 4000円くらい払ってる。それがなければ月数円。

2022-04-17

後退し続けるたわわの論点

たわわ批判派の論点が動き続けてて訳が分からない。ので整理した。

フェーズ1: ナタリー炎上

発端は日経の当該広告ではなく、ナタリーが伝えた編集部コメントという認識

【炎上】日本経済新聞の広告がジェンダークレーマー被害に遭ってしまう - Togetter

今回の新聞広告について、ヤングマガジン編集部は「4月4日今年の新入社員最初に迎える月曜日です。不安を吹き飛ばし、元気になってもらうために全面広告を出しました」と語っている。

批判の理路は各人で異なるものの、概ね「元気になってもらうため」を「現実女子高生を見て元気になって」と解釈したフェミニスト(※)が広告掲載した日経批判しているものが多かったように見える。

性的消費とか性的搾取とかの用語を使いながら、この広告掲載することは即ち日経新聞による「現実女子高生を見て元気になって」というメッセージ是認であるという主張に収斂していく様子が(主観的には)観測された。

※ 「善良なネットユーザ」でも「ジェンダークレーマー」でも好きなように適当に読み替えてください



フェーズ2: 治部れんげ准教授の3つの問題点

そんなななか、ハフポスト専門家"治部れんげ"准教授を引き連れ以下のように問題点を整理してくれた。

「月曜日のたわわ」全面広告を日経新聞が掲載。専門家が指摘する3つの問題点とは? | ハフポスト NEWS

1つ目は、あらゆる属性の人が読む最大手経済新聞掲載されたことで、「見たくない人」にも情報が届いたことだ。

第一に「『見たくない表現に触れない権利』をメディアが守れなかったこと」が問題だと主張したが、法学クラスタからの猛反発を受けて治部れんげ准教授は「私の主張のメインは法律ではありません。コメント引用で見たくないものに触れない「権利」と書いてあるので、法律論だと思った方もいるようですが。」と実質的に取り下げた。

法学出身の治部れんげ准教授第一問題点として挙げたが、法律よりむしろマナーとかそういうものに近い話だったらしい。

”見たくない表現に触れない権利”は存在しない。すでに司法で否定されていた。平裕介弁護士の解説。 - Togetter


2つ目の問題は、広告掲載によって「異性愛者の男性未成年少女性的対象として搾取する」という「ステレオタイプ」(世間的固定概念)を肯定し、新聞社が「社会的お墨付きを与えた」と見られること

2個目の問題点が当時の批判派の主流に最も近いように思える。

広告のもの問題なのか、本編の内容や編集部コメントも併せて初めて問題になるのか、など不明点はあるものの、「新聞である日経広告掲載したこと問題という主張だ。


3つ目の問題点は、これまで「メディア広告によってジェンダー平等を推進し有害ステレオタイプ撤廃するための世界的な取り組み」を国際機関とともに展開してきた日経新聞が、自ら「ジェンダーステレオタイプを強化する」という矛盾に陥ってしまたこ

この記事では記載されていないが、治部れんげ准教授UN Women 日本事務所が推進する「アンステレオタイプアライアンス」のアドバイザーである

そのアドバイザーが「「3つのP」という[...]基準に照らすと、[...]女子高生の『人格主体性』は考慮されていません」と指摘」している。

「3つのP」という基準を守れていないことが問題だと明確に主張している。



フェーズ3: 国連女性機関からの抗議

治部れんげ准教授がやや燃えたあと、同じくハフポストUN Women本部日経に抗議したことを報じた。

国連女性機関が『月曜日のたわわ』全面広告に抗議。「外の世界からの目を意識して」と日本事務所長 | ハフポスト NEWS

UN Women 日本事務所石川雅恵所長にインタビューを行い、UN Womenの問題点認識を聞いている。

UN Women 日本事務所石川雅恵所長は、今回の全面広告が、「アンステレオタイプアライアンス」の加盟規約などに反すると指摘する。

「今回の広告は、男性にとっての『女子高生にこうしてほしい』という見方しか反映しておらず、女子高生には『性的な魅力で男性応援する』という人格しか与えられていません。私たちが重視してきた『3つのP』の原則は守られていないのです」

日経新聞違反しているとされる「加盟規約など」の具体的事項は明らかにされていないが、ここでも「『3つのP』の原則は守られていない」ことが問題とされているように読める。

その上で日経新聞に「「3つのP」に反する広告掲載したこと問題視し、同社の新聞広告掲載基準見直しを」要求したという。



フェーズ4:それ以降の議論
「3つのP」はポジティブチェックの基準でありネガティブチェックは不適(不可能)では?

『月曜日のたわわ広告は「アンステレオタイプ3つのP」に反したのか』2022-04-16|ヒトシンカ ( 『シンカ論マガジン』『センサイクロペディア』 )|note

社会常識としての日経「たわわ」問題(追記済 - tikani_nemuru_M’s blog

tikani_nemuru_Mさんへの返信 - hepta-lambda’s blog

違反しているか問題だと指摘されているが、違反していないかチェックするための基準ではないのでは?という議論

基準の内容からしても、過去インタビューからしても「3つのP」は達成できると望ましい、達成に向けて努力しましょうという位置づけという解釈自然と考えられる。

もしネガティブチェックとしたら他の広告とたわわとの比較となり、たわわに恣意的適用がされていないかという別の問題があるだろう。

日経個別UN Womenと結んだ約束違反したのが問題

UN Womenが抗議した報道を受けて、複数政治家を始め表現の自由の侵害懸念する声が上がった。

国連女性機関による「月曜日のたわわ」全面広告への抗議表明について|赤松健|note

これに対し、日経がアンステレオタイプアライアンス設立メンバであり、設立メンバとして個別に交わしていた覚書に違反したことUN Womenが問題にしているのだから政治家が抗議するのは筋が違うという反論がある。

フェーズ1では社会の公器たる新聞社が広告掲載したこと問題になっていたが、ここに至ってはアンステレオタイプアライアンスに加盟していない新聞社であれば問題は無いことになる。



まとめ

「3つのP」とか「ステレオタイプ」とか言われるけど、そもそも、あの絵のどこがダメなのか誰も具体的に指摘しているところを見たことがない。

著名な社会学者小宮友根 教授がまとめた「性的客体化の表現技法」のどれにも合致していないように見える。

炎上繰り返すポスター、CM…「性的な女性表象」の何が問題なのか(小宮 友根,ふくろ) | 現代ビジネス | 講談社(1/9)

UN Womenは「「3つのP」に反する広告掲載したこと問題視し、同社の新聞広告掲載基準見直し」を要求しているが、今回のたわわ広告を弾ける現実的な基準が全く想像できない。

2022-02-20

ExcelLambda関数で何が便利になるんだろうか

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-12-07

プログラミングスクールに1ヶ月通った45歳無職童貞でもマイナビ就活できますか?

maru9 = ["大東文化大学", "東海大学", "亜細亜大学", "帝京大学", "国士舘大学"]

def mynavi_filter(students):
    return filter(lambda x: x not in maru9, students)

print(list(mynavi_filter(["東京大学", "東海大学"])))

2021-08-19

la la la lambda variant

息が止まるくらいの

2021-08-12

ワイがAWSをやらない理由

GUIダサい2010年くらいの感覚

・Cloudwatch、Lambda、S3、AMI、みたいなとっちらかった命名規則ダサい

・ただVM作るだけなのに関数みたいなのコピペさせたりとかダサい

・ところどころ英語メッセージになるのがダサい

結論ダサい

2021-08-09

スペルを思い出すためについつい正しくない読み方をする英単語

lambda・・・ランバダ式

knife・・・ナイフ

代替(だいがえ)とか重複(じゅうふく)みたいなもんか?

2021-07-09

anond:20210706022633

一応年収1100万のソフトウェアエンジニア(もちろん国内、ただしアラフォー)なのでアドバイスじゃないがどんな感じか説明

やってることはバックエンド全般最近インフラ管理画面も大体バックエンド屋さんのお仕事なので、

要はフロントエンド以外というのが正しいかな?極めてざっくりいうとアミューズメント関係イベント基盤を

AWS上で構築・運用するお仕事アプリはBFFはnodeのアプリ動画とかバッチ系はJavaで書いたアプリLambda

ECS上で運用ストレージはElastiCacheとDynamoDBを使っていて、基本的にすべての運用はEventBridgeで

Slackに飛んできて自分保守までやる感じ。これで10人のチームで回している。スマホアプリフロント

なるんだけどそっちは別のチームがやっていて多分同じぐらいの年収をもらっていると思う。

かると思うけど別に全然したことをやっていない。最新のプロトコルとかよく知らんし、

CSは一応AtCoder青とかい人材もいるにはいるけどほとんどの人は並ぐらい。

FPGAなんて多分みんな無理なんではないかな。それでもこの年収をもらえるのは単にソシャゲ業界利益率が

いからで別に俺がすごいわけではない。AWS知ってる人はわかると思うけど上のスタックって

多分駆け出しエンジニアちょっと頑張ってる程度の人が練習で作るWebサービスぐらいの技術レベルだと思う。

技術的に一応他よりは高いのかなと思うのはCD/CIかな。アミューズメント業界なので一日10回のリリースとかよくある。

なのでステージング環境OKならそのままSlackで1スタンプデプロイになっている。

基本的フロントとの互換性が取れる限りはバックエンドは無停止リリースができる。

これもEKSのおかげだな。やっぱりコンテナ技術はすごいよ。

残業時間は全社平均して10時間だけど深夜に趣味で新機能の開発とかしてるので実質200時間とかある人もいそう。

俺は一応残業は全部申告してるけど、そもそもゲーム業界裁量労働制適用できる業界なので残業代などない。

というわけで業界が好きで、かつ増田ぐらいの知識があるなら1000万は30代になったらいけるんじゃないか

20代でも500か600万は固いでしょ。ただ業界が好きかどうか/その業界が儲かってるかどうかによるので、

そこだけは妥協せずに選んでくれ。個人的に深夜まで新機能作っててもそんなに疲れないんだけど、

前職のSIerPMやってたときは定時内ですら苦痛だったわ。客とか上司の顔見るたびに作り笑いしてたけど

転職間際とか引きつってた記憶がある。ちなみに年収270万君が例に出してる会社ひとつなんだが、確かに

入社難易度は高いと思うが(主に学歴フィルターの面で)中にいる人の技術的なスキルは散々が多かったぞ。

飲み会で客とうぇーいする能力だけは高かったが。SIerなんてそんなもんなんで、いくら年収が高いからといって

技術的なことをやりたいとか、体育会系脳筋じゃない限りおすすめはしないな。

2021-06-26

anond:20210625180126

Α α alpha アルファ

Β β beta ベータ

Γ γ gamma ガンマ

Δ δ delta デルタ

Ε ε epsilon イプシロン

Ζ ζ zeta ゼータ

Η η eta イータ

Θ θ theta シータ

Ι ι iota イオ

Κ κ kappa カッパ

Λ λ lambda ラム

Μ μ mu ミュー

Ν ν nu ニュー

Ξ ξ xi クサイ

Ο ο omicron オミクロン

Π π pi パイ

Ρ ρ rho ロー

Σ σ sigma シグマ

Τ τ tau タウ

Υ υ upsilon ユプシロン

Φ φ phi ファイ

Χ χ chi カイ

Ψ ψ psi プサイ

Ω ω omega オメガ

2021-02-15

AWSをやったんだ。

Lambdaをやって AWS Lambdaをやって Containerをやって

いろいろやって

こんなの意味いね ヤムチャみたいなもの まわりがよわかっただけ いつのまにか クリリン強い

2021-02-12

S3 DBはDynamoDB

を使えば一発

Wordpressからプラグインで一発

いっしょうけんめい、気を紛らわしているのに 話しかけるってどういうことなんだろうな

 

Wordpress containerをベースに Dynamoプラグインを食わせて DynamoPressのコンテナをECRに登録してLambdaから呼び出せばいい

歯をくいしばって、1つ1つがんばってるのにな

邪魔が入る いっつもそう

周囲が総出で邪魔をする

2021-02-11

Amazon Elastic Container Registry

Wordpressの(DBはRDS)を設定してLambdaから呼び出して

Amazon LambdaPress

 

AmazouCloudFrontのLambdaEdgeからLambdaPressを呼び出して

Amazon LamdaEdgeLambdaPress

 

DBNoSQL化したS3DBSQLドライバを使って LamdaEdgeLambdaPressS3NoSQLDB

ContainerEmageがめんどい 意味もない ここまで理論を組み上げるのが大変だった

2021-02-09

anond:20210209203950

LambdaPressをLambdaEdgeで呼び出してバックエンドNoSQL化したS3をSQLラッパーアクセス 素晴らしい発想 とりあえずLambdaからS3への書き込み成功した LambdaEdgeへのデプロイもできた

2021-02-03

CloudFrontと相性が悪いため

しばらく

こっちをかしてくれ

 

やはり年単位で調整を繰り返しているが

ブログコメント欄

相性が悪いな

コメントスパムもあるから

PHP直撃にすると、こんどはクローラーに潰される

急激な1日だけの大手サイトリンク対応するとCDNになって、コメント対応できない

 

調整がめんどくさいことこの上ない

バランスが難しいね

どうしてもコメントを開けようとすると

ロードバランサー入れてPHPマルチにしないと負荷に耐えられないが

わずか1年で1日未満のあめに、のこりをずっとあげておけはたしかに無謀

Lambda pressでリミッター入れる以外の方法にたどり着けない

2021-01-29

サーバ代1万円/月は個人にはかかりすぎ、

とはいえlambda@pressなんて、1万円をかかりすぎという集団に、できてあたりまえとは言いづらい。

だめではないけど、やや敷居が高い

2021-01-28

anond:20210128173042

EC2コンテンツLambda化とか、初見からかなり時間くっているけど、2回目から爆速ってわかりきってる

これって、知らなかった場合に、いかに早く調べて、対応できるか?のテストだよねぇ?

知ってることを、答えてもテストにならないもんな 初見縛りとかきついよな

 

EC2知ってる

Lambda知ってる

EC2の今のコンテンツコンテナ化してダイエットしてLambda移行 初見

 

1回測っときゃ、企業としては

ほかの知らないことを新規に頼んだ場合も似たような速度の10倍ぐらいだろうから

2021-01-25

200万ぐらい。20年間のサーバ代。

EC2とかAWSとかLambda GCP 無駄金つかって がんばった。

いらね。無料サイトなら無料だった。頑張る必要がないことを、がんばったんだなぁと察した。

おれでは、金にならない。RDSもいつのまにか、マルチAZからシングルAZになてた。

それなら、EC2自分でたてたほうが、はやくねーか?

そもそも

wordpressなら、SQLいらね。ファイルだけのほうがはるかにいい。

殺してくれっておもうから戦争必要だったんだなぁとわかった。若い子は大丈夫

いわれたとおりにやって、エスカレーターにのって

35歳でキャッシュで部屋買って定年で、あとは、バイト

それで幸せになれるよ

2021-01-24

anond:20210124113829

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

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

anond:20210124104212

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

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

2021-01-22

方向性は見えてきた

画像はS3で配信するとして、Apacheを通さな

Wordpressをどうするかだが、画像がないApacheなら少しは軽くなる

あとはコメント欄 どうせ使われてもいない 機能にたいしてクラックくらった場合にどうするか?なんだろうなぁ めんどくせぇ

そりゃ多数のサイトが閉鎖するわ

lambda pressにすると 逆にクローラー食らうと金がかかりすぎそう

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