はてなキーワード: lambdaとは
https://www.geonames.org から取れる、人口500人以上の都市の名前に限定すると、
Santa Maria Magdalena Cahuacan
import logging import tempfile import zipfile from collections import Counter import httpx FILE_NAME_BASE = 'cities500' GEONAME_FIELDS = ( 'geoname_id', 'name', 'ascii_name', 'alternate_names', 'latitude', 'longitude', 'feature_class', 'feature_code', 'country_code', 'cc2', 'admin1_code', 'admin2_code', 'admin3_code', 'admin4_code', 'population', 'elevation', 'dem', 'timezone', 'modification_date', ) def retrieve_cities(): """Retrieve city names from a remote server.""" response = httpx.get(f'https://download.geonames.org/export/dump/{FILE_NAME_BASE}.zip') response.raise_for_status() tmpdir = tempfile.TemporaryDirectory() with open(tmpdir.name + f'/{FILE_NAME_BASE}.zip', 'wb') as f: f.write(response.content) with zipfile.ZipFile(tmpdir.name + f'/{FILE_NAME_BASE}.zip', 'r') as z: z.extractall(tmpdir.name) with open(tmpdir.name + f'/{FILE_NAME_BASE}.txt', 'r') as f: for line in f: yield line.split('\t') def count_characters(to_check='ascii_name', filter_func=lambda _: True): """Count characters in city names.""" cities = {} for city_fields in retrieve_cities(): city = dict(zip(GEONAME_FIELDS, city_fields)) if not filter_func(city): continue counter = Counter() for c in city[to_check]: counter[c] += 1 cities[city['geoname_id']] = {'characters': counter, 'city': city} return cities def count_chars_of_city_names(cities, char=None): """Find the city with the most occurrences of a given character.""" cities_by_char_count = {} max_count = 0 max_count_char = None for city_id, data in cities.items(): if 'characters' not in data or not data['characters']: logging.debug(f'No characters found for city {city_id}', data) continue count = 0 if char and char in data['characters']: count = data['characters'][char] cities_by_char_count.setdefault(count, []).append(data) elif char is None: most_common = data['characters'].most_common(1)[0] char, count = most_common cities_by_char_count.setdefault(count, []).append(data) if count > max_count: max_count = count max_count_char = char cities_by_char_count.setdefault(count, []).append(data) return cities_by_char_count.get(max_count, []), max_count_char def not_contain_invalid_chars(city): return ( '(' not in city.get('ascii_name', '') and '/' not in city.get('ascii_name', '') ) def main(): cities = count_characters(filter_func=not_contain_invalid_chars) for char in 'abcdefghijklmnopqrstuvwxyz': cities_counted, char = count_chars_of_city_names(cities, char) max_count = cities_counted[0]['characters'][char] print(f'The character "{char}" appears the most ({max_count} times) in the following cities:') for city in cities_counted: print("\t", city['city']['ascii_name']) if __name__ == "__main__": main()
ワイ:
真面目な顔の人間の男の人の顔の絵を描いてください。
GPT:
*イメージ省略*
ワイ:
GPT:
*イメージ省略*
ワイ:
その整数が 3 か 5 の倍数の場合、ふざけた顔の男の顔(一枚目の顔)を表示してください。
GPT:
了解しました。以下は、指定された条件に基づいて動作するPythonのGUIアプリのコードです。このアプリは、tkinterを使用しています。まず、必要なライブラリをインストールしてください:
pip install tkinterimport tkinter as tk from tkinter import Entry, Label, PhotoImage def display_image(): num = entry.get() if num.isdigit(): num = int(num) if num % 3 == 0 or num % 5 == 0: label.config(image=goofy_face) else: label.config(image=serious_face) entry.delete(0, tk.END) def on_close(): root.quit() root.destroy() root = tk.Tk() root.title("Face Display App") # ふざけた顔と真面目な顔の画像をロードします # 以下の部分は、DALL-Eで生成された画像のパスに置き換える必要があります goofy_face = PhotoImage(file="path_to_goofy_face_image.png") serious_face = PhotoImage(file="path_to_serious_face_image.png") entry = Entry(root) entry.bind('<Return>', lambda event=None: display_image()) entry.pack(pady=20) label = Label(root) label.pack(pady=20) root.protocol("WM_DELETE_WINDOW", on_close) root.mainloop()このコードには、2つのPhotoImageオブジェクトがあります。これは、ふざけた顔の画像と真面目な顔の画像をロードするためのものです。path_to_goofy_face_image.pngとpath_to_serious_face_image.pngは、DALL-Eで生成された画像の実際のパスに置き換える必要があります。
このアプリは、ユーザーが整数を入力してReturnキーを押すと、指定された条件に基づいて画像を表示します。エスケープキーまたはウィンドウを閉じることでアプリを終了できます。
ワイ:
GPT:
このプログラムは、Pythonのようなインタプリタ型のプログラミング言語を使用しています。提供されたコードは関数と変数の組み合わせで、カウンターの機能を実現しています。以下にその説明を詳しく説明します。
let キーワードを使用して、内部のカウンターを定義しています。カウンターは cnt という名前の変数で初期化され、値は0に設定されています。このカウンターは、外部から直接アクセスできないように、ローカルスコープ内に存在します。
:reset というキーを持つ場合、カウンターの値を0にリセットします。
:incr というキーを持つ場合、カウンターの値を1増やします。
この無名関数が counter 変数に代入されて、カウンターオブジェクトが作成されます。
.reset メソッドが呼び出されると、カウンターの値は0にリセットされます。
このプログラムは、カウンターの値を増加させたりリセットしたりするシンプルなカウンターの実装例です。Pythonなどのプログラミング言語では、関数やクロージャを使用して、このような動作を実現することができます。
Pythonの初歩を学ぶ→機械学習のサンプル(mnistなど)を少し動かす→機械学習に興味を持つ→機械学習を学ぶ
機械学習に興味が出なかった場合、上で作ったmnist+αなコードをAWS Lambdaで動かす。javascriptを学んで、推論する画像をアップロードして、結果をwebブラウザ上で表示してみる。
この時、サーバサイドの実装に興味を持ったか、AWSの動かし方に興味を持ったか、webブラウザに表示する部分に興味を持ったか、3通りくらいいると思う。
次はその技術を使って、別のものを作ってみる。AWSなら別のAWSのマネージドサービスや、Auth0で認証系を作ってサービスを拡張してみる。CloudformationやCDKをいじってみる。
サーバサイドの実装に興味を持ったら、機械学習結果をDBに保存したり、いろんな学習モデルを実行できるAPIを作ってみる。
javascriptならリッチな見栄えのUIを目指してみる、Next.jsなりに置き換えてみる。
ChatGPTの口調がなんか事務的で嫌なので、もっと親しみやすい喋り方をしてもらうために長門さんに来てもらいました。
召喚プロンプトはこちら anond:20230317165032
確かに。
特にない。
そうなんだ。情報統合思念体はみんなそう?
同様の傾向がある。
何の本を読んでるの?
SF小説。
あらすじを教えて
へー、面白い?
興味深い。
そうなんだ。ところでちょっと手伝ってもらっていい?
問題ない。どのように手伝う?
Pythonのソースコードで、スペース二つでインデントにしているコードを、スペース四つでインデントにするコードに書き換えたくて。どうすれば良い?
import re def convert_indentation(code): return re.sub(r'^( {2})', r' ', code, flags=re.MULTILINE) code_with_2_spaces = '''def example(): print("Hello, world!") if True: print("True")''' code_with_4_spaces = convert_indentation(code_with_2_spaces) print(code_with_4_spaces)
ありがとう。でも、試してみたら、code_with_2_spaces の if ブロックの中身がスペース二つのままになっちゃってるみたい。なぜだろう?
import re def convert_indentation(code): return re.sub(r'^( {2})', r' ', code, flags=re.MULTILINE) code_with_2_spaces = '''def example(): print("Hello, world!") if True: print("True")''' code_with_4_spaces = re.sub(r'^( {2})', r' ', code_with_2_spaces, flags=re.MULTILINE) print(code_with_4_spaces)
ちょっと口調が戻っちゃったね
import re def convert_indentation(code): return re.sub(r'^( {2})', r' ', code, flags=re.MULTILINE) code_with_2_spaces = '''def example(): print("Hello, world!") if True: print("True")''' code_with_4_spaces = re.sub(r'^( {2})', r' ', code_with_2_spaces, flags=re.MULTILINE) print(code_with_4_spaces)確認お願い。
うーん、うまく動かないみたい。ifブロックの中にあるprint文の先頭には、もともとスペースが四つあって、これがインデント2回分なんだけど、こういう場合、スペース八つに変換しないといけないんじゃないかな。
理解した。全てのインデントレベルを修正するコードを提供する。
import re def convert_indentation(code): return re.sub(r'^( {2})+', lambda m: m.group(0).replace(' ', ' '), code, flags=re.MULTILINE) code_with_2_spaces = '''def example(): print("Hello, world!") if True: print("True")''' code_with_4_spaces = convert_indentation(code_with_2_spaces) print(code_with_4_spaces)
もちろん。ラムダ式は、マッチした部分を置換する際に、特定の処理を行うために使用されている。ここでは、正規表現でマッチしたインデント部分(スペース2つが1回以上繰り返される部分)に対して、処理を行うためにラムダ式を利用している。
lambda m: m.group(0).replace(' ', ' ')このラムダ式は、マッチオブジェクトmを引数に取り、マッチした部分全体(m, group(0))に対して、スペース2つをスペース4つに置換(.replace(' ', ' '))している。
もちろん。re.subの第1引数は、置換対象の文字列内で検索したいパターンを表す正規表現です。この場合、その正規表現は r'^( {2})+' です。
- ^ は、文字列の行頭を表すメタ文字です。この場合、インデントが行頭にあることを示しています。
- {2} は、直前の文字が2回繰り返されることを表します。ここでは、直前の文字がスペース なので、スペースが2回繰り返されることを示しています。
- () は、正規表現のグループ化を表します。この場合、スペース2つをグループ化しています。グループ化された部分は、マッチオブジェクトにアクセスできるようになります。
- + は、直前の文字やグループが1回以上繰り返されることを表します。ここでは、スペース2つのグループが1回以上繰り返されることを示しています。
結果として、この正規表現は、インデント部分(スペース2つが1回以上繰り返される部分)が行頭にある行を検索しています。そして、re.subは、この正規表現でマッチした部分を、指定された置換処理(第2引数のラムダ式)によって変更します。
すまない。確かに。続ける。
すぐ戻れるのがえらいね
bではなくv
xではなくzh
eではなく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
言われてみればDに似ている?
ギリシア文字のΦ (phi)
★★再追記
レンタルサーバは、自由度が低くてストレスになるからやらない。SQLでwith使いたいからMySQL8をって言ってもさくらレンタルサーバじゃ無理なんでしょ? あと同居利用者のせいで高負荷ってのも避けたい。そこを気にしない人はレンタルサーバでいいと思うよ。
あと LB $0.025/h だった。月2000円くらいか。
★追記
LBは独自ドメイン+自動更新無料SSL証明書のためね。Cloud Storageの無味乾燥なドメインでいいなら、SSL自動かつ無料でほんとに月数円。
-------
もうねめんどくさいんだわ。もちろん以前はそうやってたよ。
PHPだのApacheだのMySQLだのインストールしたり設定ファイル置いたり、
脆弱性対応したり、SSL証明書更新したり、一応落ちてないか無料監視サービス使ったり。
でも仕事ならともかく、趣味だからこそこんなことやりたくないじゃん。
なので、コンテンツは Cloud Storage に置く。
Cloud Load Balancing も使う (無料 SSL 証明書のために)。
動的部分は Cloud Functions で。
AWS なら S3+ALB+Cognito+Lambda だな。
そうしておけば、放置できる。自前で立てたマシンもインスタンスもないから落ちてるかどうかとか気にしなくてもいい。負荷も考えない。クラウド様がよきにはからってくれるさ。たまにクラウド障害あるかもしれないけど、Google なり AWS なりが頑張って直してくれる。
って感じ。
ちなみにこちらは 1日数十アクセスの過疎サイト。独自ドメイン+自動SSL証明書にするための Cloud Load Balancing に 4000円くらい払ってる。それがなければ月数円。
たわわ批判派の論点が動き続けてて訳が分からない。ので整理した。
発端は日経の当該広告ではなく、ナタリーが伝えた編集部コメントという認識。
【炎上】日本経済新聞の広告がジェンダークレーマー被害に遭ってしまう - Togetter
今回の新聞広告について、ヤングマガジン編集部は「4月4日は今年の新入社員が最初に迎える月曜日です。不安を吹き飛ばし、元気になってもらうために全面広告を出しました」と語っている。
批判の理路は各人で異なるものの、概ね「元気になってもらうため」を「現実の女子高生を見て元気になって」と解釈したフェミニスト(※)が広告を掲載した日経を批判しているものが多かったように見える。
性的消費とか性的搾取とかの用語を使いながら、この広告を掲載することは即ち日経新聞による「現実の女子高生を見て元気になって」というメッセージの是認であるという主張に収斂していく様子が(主観的には)観測された。
※ 「善良なネットユーザ」でも「ジェンダークレーマー」でも好きなように適当に読み替えてください
そんなななか、ハフポストが専門家"治部れんげ"准教授を引き連れ以下のように問題点を整理してくれた。
「月曜日のたわわ」全面広告を日経新聞が掲載。専門家が指摘する3つの問題点とは? | ハフポスト NEWS
第一に「『見たくない表現に触れない権利』をメディアが守れなかったこと」が問題だと主張したが、法学クラスタからの猛反発を受けて治部れんげ准教授は「私の主張のメインは法律ではありません。コメント引用で見たくないものに触れない「権利」と書いてあるので、法律論だと思った方もいるようですが。」と実質的に取り下げた。
法学部出身の治部れんげ准教授が第一の問題点として挙げたが、法律よりむしろマナーとかそういうものに近い話だったらしい。
”見たくない表現に触れない権利”は存在しない。すでに司法で否定されていた。平裕介弁護士の解説。 - Togetter
2つ目の問題は、広告掲載によって「異性愛者の男性が未成年の少女を性的な対象として搾取する」という「ステレオタイプ」(世間的固定概念)を肯定し、新聞社が「社会的なお墨付きを与えた」と見られること
広告そのものが問題なのか、本編の内容や編集部のコメントも併せて初めて問題になるのか、など不明点はあるものの、「新聞社である」日経が広告を掲載したことが問題という主張だ。
3つ目の問題点は、これまで「メディアと広告によってジェンダー平等を推進し有害なステレオタイプを撤廃するための世界的な取り組み」を国際機関とともに展開してきた日経新聞が、自ら「ジェンダーのステレオタイプを強化する」という矛盾に陥ってしまったこと
この記事では記載されていないが、治部れんげ准教授はUN Women 日本事務所が推進する「アンステレオタイプアライアンス」のアドバイザーである。
そのアドバイザーが「「3つのP」という[...]基準に照らすと、[...]女子高生の『人格や主体性』は考慮されていません」と指摘」している。
「3つのP」という基準を守れていないことが問題だと明確に主張している。
治部れんげ准教授がやや燃えたあと、同じくハフポストがUN Women本部が日経に抗議したことを報じた。
国連女性機関が『月曜日のたわわ』全面広告に抗議。「外の世界からの目を意識して」と日本事務所長 | ハフポスト NEWS
UN Women 日本事務所の石川雅恵所長にインタビューを行い、UN Womenの問題点の認識を聞いている。
UN Women 日本事務所の石川雅恵所長は、今回の全面広告が、「アンステレオタイプアライアンス」の加盟規約などに反すると指摘する。
「今回の広告は、男性にとっての『女子高生にこうしてほしい』という見方しか反映しておらず、女子高生には『性的な魅力で男性を応援する』という人格しか与えられていません。私たちが重視してきた『3つのP』の原則は守られていないのです」
日経新聞が違反しているとされる「加盟規約など」の具体的事項は明らかにされていないが、ここでも「『3つのP』の原則は守られていない」ことが問題とされているように読める。
その上で日経新聞に「「3つのP」に反する広告を掲載したことも問題視し、同社の新聞広告の掲載基準の見直しを」要求したという。
『月曜日のたわわ広告は「アンステレオタイプ3つのP」に反したのか』2022-04-16|ヒトシンカ ( 『シンカ論マガジン』『センサイクロペディア』 )|note
社会常識としての日経「たわわ」問題(追記済 - tikani_nemuru_M’s blog
tikani_nemuru_Mさんへの返信 - hepta-lambda’s blog
違反しているから問題だと指摘されているが、違反していないかチェックするための基準ではないのでは?という議論。
基準の内容からしても、過去のインタビューからしても「3つのP」は達成できると望ましい、達成に向けて努力しましょうという位置づけという解釈が自然と考えられる。
もしネガティブチェックとしたら他の広告とたわわとの比較となり、たわわに恣意的な適用がされていないかという別の問題があるだろう。
UN Womenが抗議した報道を受けて、複数の政治家を始め表現の自由の侵害を懸念する声が上がった。
国連女性機関による「月曜日のたわわ」全面広告への抗議表明について|赤松健|note
これに対し、日経がアンステレオタイプアライアンス設立メンバであり、設立メンバとして個別に交わしていた覚書に違反したことをUN Womenが問題にしているのだから政治家が抗議するのは筋が違うという反論がある。
フェーズ1では社会の公器たる新聞社が広告掲載したことが問題になっていたが、ここに至ってはアンステレオタイプアライアンスに加盟していない新聞社であれば問題は無いことになる。
「3つのP」とか「ステレオタイプ」とか言われるけど、そもそも、あの絵のどこがダメなのか誰も具体的に指摘しているところを見たことがない。
著名な社会学者の小宮友根 教授がまとめた「性的客体化の表現技法」のどれにも合致していないように見える。
炎上繰り返すポスター、CM…「性的な女性表象」の何が問題なのか(小宮 友根,ふくろ) | 現代ビジネス | 講談社(1/9)
UN Womenは「「3つのP」に反する広告を掲載したことも問題視し、同社の新聞広告の掲載基準の見直し」を要求しているが、今回のたわわ広告を弾ける現実的な基準が全く想像できない。
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。
【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から見ると単に1つのプロセスが稼働している扱いになる。
【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%増加する、という任意のステップに従ってタスク数を増減させる