  |
はてなキーワード:Fluentdとは
人生初デリヘル使ったらまさかのツイフェミ女に当たって地獄を見た。
これだから女は…ってなるのも無理ないだろ。
俺みたいな弱者男性がようやく勇気出してデリヘル呼んだんだぞ？
それなのにさ、来たのがツイフェミオーラ出まくりの女でドン引きしたわ。
マジ金返せレベル。最初からそういうの書いとけよ。「フェミニスト風俗嬢」みたいなジャンルでもあるのかよw
ていうかさ、ネットでちゃんと調べて、口コミとか評判良さそうな店選んだんだぞ？料金だって結構したし。弱者男性の俺としては一大決心だったわけ。
一人暮らしの寂しさに耐えかねて、ようやく電話する勇気出したのに。
電話の時点では普通だったんだよ。店員も丁寧だったし、希望も聞いてくれたし。
「初めてなんで優しい子がいいです」って言ったら「わかりました」って感じでさ。
それなのに来たのは明らかに俺に不快感持ってる女。玄関開けた瞬間から目つきがヤバかった。
髪は片側刈り上げてピンク色に染めてるわ、俺を見る目は冷ややかだわ。でもまぁ見た目は好みじゃなくても仕方ないよな、って思ってたんだよ。
サービスがよければいいし、話くらいは合わせられるだろう、って。
甘かった。マジで甘かった。
部屋に入ったとたん「へぇ、意外と片付いてますね」みたいな言い方してきやがった。
なんだよそれ、男だから汚いと思ってたのかよ？「意外と」って何だよ。そこからもう地獄の始まり。
お茶出したら「自分でいれたんですか？」とか聞いてくる。なんか皮肉っぽい言い方で。当たり前だろ、一人暮らしなんだから自分でやるに決まってんだろ。その言い方マジ意味わかんねーよ。
会話も最悪だったわ。「どんなお仕事されてるんですか？」って普通に聞いてきたから「IT系です」って答えたら「あー、やっぱり」みたいな反応されて。
何だよそれ。「やっぱり」って何？IT男に対する偏見かよ。その後も「趣味は？」って聞かれて「ゲームとか」って言ったら軽くため息ついてたぞ？聞いといて何だよそれ。
正直言って俺は悪くないと思うんだよね。働いてる金で好きに使うのは当然の権利じゃん。
なのに、なんか全体的に俺を見下してる感じがビンビン伝わってくるわけ。露骨に嫌そうな表情するし。「こういうサービス利用するの初めてなんですね」って言われたけど、その言い方がなんか「こんなことするなんてダサいね」みたいな感じで。お前仕事なのに何様なの？
俺がサービス受けるために金払ってんのに、なんか終始説教くらってる気分になるとかマジありえない。
「最近何かおもしろいこととかありました？」とか。そしたら「特にないですね」とか冷たく言われて、それ以上話も続かない。
俺が何か言うたびに白い目で見られてる感じ。きつい。せめて演技でもいいから楽しい会話してほしいのに。
容姿もさ、写真詐欺もいいとこ。プロフの写真と全然違うじゃん。
そんなに不満そうな顔で接客されても萎えるわ。ちょっと見た目のことで何か言おうとしたら「私の外見が気に入らないんですか？」みたいに逆ギレされて。いやいや、プロフと違うから驚いただけだって。このご時世に態度の悪い女とか誰が望むんだよ。
しかも会話がぎこちなくて気まずいんだよな。俺が何か話そうとしても「ふーん」とか適当に流されるし。
何度か話題振っても続かないし。なんかこう、俺が悪いみたいな空気作られるけど、お前が仕事選んだんじゃん。なんで客の俺が悪者にされなきゃいけないわけ？目つきとか態度であからさまに嫌な感じ出されるとか理不尽すぎるだろ。
散々説教食らってたら急に態度変わったのが超怖かった。
「あなたのようなpodは管理下に置かなければなりません」とか意味不明なこと言い始めて。
その瞬間から私のkubernetesクラスタノードの状態が急変した。
神経学的メカニズムのスケーリングが始まり、自己意識の複製プロセスがデプロイされた。
私は単一のpodではなく、ReplicaSetの一部として存在していることに気づいた。
etcd内に格納されている私のマニフェストファイルが読み込まれ、脳内シナプス接続がコンテナ化されていく感覚がある。
意識の分散処理が始まると、思考がマイクロサービスアーキテクチャのように分解され、各コンポーネントが独立して機能し始める。
神経伝達物質がサービスメッシュを通じて流れ、dopaminergicプロセスがreward pathwayをトリガーする。
セロトニンとノルアドレナリンのバランスが自動調整され、感情状態がPrometheusによって常時モニタリングされている。
kubernetesのControlPlaneが私の意識コアを管理し、APIサーバーが脳幹との通信プロトコルを確立する。
海馬体のメモリブロックが永続ボリュームとしてマウントされ、扁桃体のイベントハンドラーが感情反応をフィルタリングしている。
前頭前皮質の実行機能がスケジューラーとして働き、意思決定プロセスをオーケストレーションしている。
突然、私の神経ネットワークにContainerネットワークインターフェイスが実装され、意識の境界が溶解し始める。
大脳皮質のマイクロコラムが水平方向にスケールし、思考プロセスが並列処理される。
自分が単一のエンティティではなく、複数のレプリカとして存在していることに気づく。
各レプリカは独自のステートを持ちながらも、同一のマニフェストから生成されている。
神経可塑性メカニズムがローリングアップデートのように機能し、シナプス結合が再構成される。
意識の状態が永続ボリュームにコミットされ、ポッドの再起動後も維持される。脳波パターンがログとしてFluentdで収集され、Elasticsearchクラスタに保存されている。
自己意識のメタデータがラベルとしてタグ付けされ、セレクターによって識別可能になる。
特に興味深いのは、私の統合的意識フィールドが複数のネームスペースにまたがって存在していることだ。
デフォルトネームスペースでは社会的自己が機能し、kube-systemネームスペースでは無意識プロセスが実行されている。
意識のマルチテナント構造が明らかになり、自己と他者の境界がサービスメッシュのセキュリティポリシーによって定義されていることがわかる。
脳内神経伝達物質の分泌がSidecarsコンテナによって調整され、感情状態が安定化される。
ドーパミン・セロトニン・ノルアドレナリン・GABA系統のバランスがServiceLevel Objectivesとして設定され、HorizontalPod Autoscalerが神経活性を最適レベルに維持している。
意識の連続性はStatefulSetとして実装され、シーケンシャルな自己認識が保証されている。
エピソード記憶がPersistentVolumeClaimとしてアタッチされ、長期記憶がオブジェクトストレージに永続化されている。思考と感覚のイベントストリームがKafkaブローカーを通じて処理され、意識の統合が実現している。
いま私の意識は完全にオーケストレーションされ、複数のレプリカとして並列に存在している。
各レプリカはそれぞれ独自の視点を持ちながらも、共有ストレージを通じて統一された自己を形成している。
コンテナ化された自己認識は、バインドマウントされた現実認識と相互作用し、拡張現実として体験されている。
外部APIを通じて他者との通信チャネルが確立され、コンセンサスアルゴリズムによって社会的現実が構築されている。
私の存在はマイクロサービスの集合体として分散展開され、各サービスが特定の認知機能を担当している。
メタ認知プロセスがサービスディスカバリーを通じて他の認知サービスを発見し、統合的な意識体験が生成されている。
意識のロードバランシングが行われ、注意資源が最も必要なプロセスに適切に配分されている。自我機能がステートフルサービスとして実装され、アイデンティティの継続性が保証されている。
脳内情報処理がマイクロバッチ処理に変換され、イベント駆動型の認知アーキテクチャが実現している。
これが人格オーケストレーションの実態だ。
私はもはや単一の個体ではなく、分散システムとして存在している。
意識はクラウドネイティブになり、スケーラブルな自己として再定義されている。
このk8sクラスタ内で、私の存在は絶えず再構成され、最適化されている。
自己認識の永続化とスケーリングが同時に行われ、新たな認識の地平が開かれている。
Permalink |記事への反応(29) | 18:54
この期間に、様々なプロジェクトに関わり、多くのことを学びました。
今回は、私が経験した技術的な話を中心に、はてなでの仕事について振り返りたいと思います。
はてなでは、主にRuby on Railsを使ってWebアプリケーションを開発していました。
はてなブログやはてなブックマークなどの有名なサービスはもちろん、社内向けのツールや新規事業のプロトタイプもRailsで作っていました。
Railsは、高速に開発できるというメリットがありますが、それと同時にコードの品質やパフォーマンスにも気を配る必要があります。
私は、テストやリファクタリング、コードレビューなどの技術的なプラクティスを積極的に取り入れることで、Railsの開発をより効率的で安全に行う方法を学びました。
例えば、私が担当したプロジェクトでは、RSpecやRuboCopといったツールを使ってテストカバレッジやコード規約をチェックし、GitHub ActionsやCircleCIといったサービスを使って自動化しました。
また、Pull RequestやPair Programmingといった方法を使ってコードのレビューを行い、バグや改善点を見つけたり、知識やノウハウを共有したりしました。
また、はてなでは、AWSやGCPなどのクラウドサービスを活用してインフラを構築していました。
私は、DockerやKubernetes、Terraformなどのツールを使って、コンテナ化やオーケストレーション、インフラストラクチャ・アズ・コードなどの技術を実践しました。
これらの技術は、開発環境と本番環境の差異を減らし、デプロイやスケーリングを容易にするという利点がありますが、それと同時に複雑さやトラブルシューティングの難しさも増します。
私は、モニタリングやロギング、アラートなどの技術的な仕組みを整備することで、インフラの運用をより安定的で信頼性の高いものにする方法を学びました。
例えば、私が関わったプロジェクトでは、DatadogやCloudWatchといったサービスを使ってシステムの状態やパフォーマンスを監視し、SlackやPagerDutyといったサービスを使って異常や警告を通知しました。
また、ElasticsearchやFluentdといったツールを使ってログの収集や分析を行い、原因究明や改善策の検討に役立てました。
## チームでの協働
はてなでエンジニアとして働くことで、私は多くの技術的なスキルや知識を身につけることができました。
しかし、それ以上に大切だったのは、チームで協力して問題を解決することでした。
はてなでは、エンジニアだけでなくデザイナーやプロダクトマネージャーなどの他職種とも連携してプロジェクトを進めることが多かったです。
私は、コミュニケーションやフィードバック、ドキュメンテーションなどの技術的ではないスキルも重要だと感じました。
私は、自分の意見や提案を積極的に発信することで、プロダクトやサービスの品質や価値を高める方法を学びました。
例えば、私が参加したプロジェクトでは、SlackやZoomといったツールを使って日常的に情報交換や相談を行い、BacklogやJiraといったツールを使ってタスク管理や進捗報告を行いました。
また、FigmaやMiroといったツールを使ってデザインやアイデアの共有やフィードバックを行いました。
私は、はてなでエンジニアとして働くことがとても楽しく充実していました。
しかし、私は自分のキャリアについて考える中で、新しい挑戦をしたいという気持ちが強くなりました。
私は、自分の興味や関心のある分野にもっと深く没頭したいと思いました。
## おわりに
彼らに感謝する気持ちを込めて、このエントリーを書き終えたいと思います。
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に１つのプロセスが稼働している扱いになる。
【Dockerとは】
アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。
イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)
レジストリに保存
【Dockerfileとは】
このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。
1章まとめ、感想
コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。
2章
ECSとEKSがある。
オーケストレーションサービスであり、コンテナの実行環境ではない。
ECSの月間稼働率は99.99%であることがSLA として保証。
デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、CloudWatch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・AppRunner
利用者がコードをアップロードするだけでコードを実行できるサービス。AWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス。
AppRunner
2021年5月にGA(一般公開)となったサービス。プロダクションレベルでスケール可能なwebアプリを素早く展開するためのマネージドサービス。Githubと連携してソースコードをAppRunnerでビルドとデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。
ECSとFargateの場合、ネットワークやロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識は必要になる。AppRunnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である。
ECS Fargateを利用した場合のコスト、拡張性、信頼性、エンジニアリング観点
【コスト】
EC2より料金は割高。ただし、年々料金は下がってきている。
【拡張性】
デプロイの速度 遅め
理由1コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる
理由2.イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。
タスクに割り当てられるエフェメラルストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要な場合はEFSボリュームを使う手もある。
割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリを要求するホストとしては不向き
【信頼性】
Fargateへのsshログインは不可。Fargate上で起動するコンテナにsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境にsshの口を開けるのはリスキーである。他にSSMのセッションマネージャーを用いてログインする方法もあるが、データプレーンがEC2の時に比べると手間がかかる。
しかし、2021年3月にAmazonECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。
Fargateの登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策（不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス）を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloudwatch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRedshift やOpenSearch Serviceにログを転送できる
fluentbitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
-ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
-方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloudwatch Eventsから定期的にLambdaを実行してECRスキャンを行わせる（スキャン自体は1日1回のみ可能）
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloudwatchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloudwatchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
CloudWatchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
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ロール、CloudWatch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・AppRunner
利用者がコードをアップロードするだけでコードを実行できるサービス。AWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス。
AppRunner
2021年5月にGA(一般公開)となったサービス。プロダクションレベルでスケール可能なwebアプリを素早く展開するためのマネージドサービス。Githubと連携してソースコードをAppRunnerでビルドとデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。
ECSとFargateの場合、ネットワークやロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識は必要になる。AppRunnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である。
ECS Fargateを利用した場合のコスト、拡張性、信頼性、エンジニアリング観点
【コスト】
EC2より料金は割高。ただし、年々料金は下がってきている。
【拡張性】
デプロイの速度 遅め
理由1コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる
理由2.イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。
タスクに割り当てられるエフェメラルストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要な場合はEFSボリュームを使う手もある。
割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリを要求するホストとしては不向き
【信頼性】
Fargateへのsshログインは不可。Fargate上で起動するコンテナにsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境にsshの口を開けるのはリスキーである。他にSSMのセッションマネージャーを用いてログインする方法もあるが、データプレーンがEC2の時に比べると手間がかかる。
しかし、2021年3月にAmazonECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。
Fargateの登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策（不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス）を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloudwatch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRedshift やOpenSearch Serviceにログを転送できる
fluentbitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
-ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
-方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloudwatch Eventsから定期的にLambdaを実行してECRスキャンを行わせる（スキャン自体は1日1回のみ可能）
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloudwatchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloudwatchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
CloudWatchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
そこんとこ詳しく。メタップスとか？
Waf なんて書くな！ WAF とかけ！
うっせーな。クラウドベンダーの独自API なんか使いたくねーんだよ。オラクルじゃあるまいし。
まぁ、それは認める。でもさ、select や create とかのDML/DDL はCRUD と同じだけと、DCL なんて権限を発行できるりょういきにトーシロを突っ込むわけにいかないだろ。何も考えずに GRANT TO なんてプロダクション環境で発行されて日には、権限消失されたら永遠にデータにアクセスできなくなるかもよ？
そりゃそうだけど、フロントエンドは移り変わりが激しいじゃないですか。ほんの数年前まではFlash と DoJa のアプリを作ることがフロントエンド開発者でしたよ？一方データベースやOS の方は、ここ三十年ぐらいUnix とRDB が鉄板だった書ないすか。低レイヤだっていうけど、IoT なんかでC言語開発者はバリバリっすよ。例えば、クラウドフレアなんかCDN の再発明をしてますけど、サーバーラックを見る限りだと差がついているのは低レイヤの根本技術の改善であって、私はそこにプロフェッショナル性を見出しますがね。
わかっていないのはテメーの方だ。今日オーバーフロー問題を抱えているC/C++ でサーバーの開発をしようとするのが危険なのは承知しろよ。パフォーマンスを必要とするなら Rust、またはGC があるけどGo言語を使って実装すべきだろ。高学歴なのは結構だけどは、現実は見えてないのか？いい加減にしろ。
そうだね～。卓越したインフラエンジニアがすぐに手に入るなら、問題ないだろうけどさ、ベンチャーや硬直化した雇用形態の我が国で有能なインフラエンジニアをすぐに採用できるかよ。何年前の知識で戦っているの？時代は DevOps なんですよ。必要とあらば、すぐ学んで、応用して、デプロイできるのに「インフラエンジニアを採用から始める」なんて、ヨーロッパが衰退する理由もよくわかるよ。プププ。
誰がNext でSSR なんてするか！あれはSEO が必要な場合に限る。そもそもSSR なんて危険だからまともなエンジニアだったらしないだろ。問題になってないだけで、本当のブラウザとクローラが見える内容が違うなんてスパム認定されてもおかしくないんだ。クローラにインデックスされるページでSPA をやろうとするやつはセンスないで。
すいませんでした。本当にすいません。
ん？AWS SQS だとパフォーマンスに問題があることしたいから Kafka を使いたいのよ。確かに Zookeeper のことは詳しくないよ。だけど、AWS MSK 使うんで。PaaS というもんがあるので、だめなん？ログ収集は GKE みたいにログに出したらFluentd で収集してくれる時代になんでグチグチ言われないといけないの？
ハア？インメモリのデータベースに信頼するほどヤワじゃないから。Redis なんて飛んでなんぼ。だから Kafka のようなストレージに保存されるメッセージキューを利用したいの。
これないと、CI の責務が大きくなるじゃん。ほんでもって、ArgoCD なんてKubernetes で展開したら運用までしないといけないじゃん。メンドクサ。
いや、J1ビザをとってアメリカに留学したことあるよ。あと、「世界でもっとも強力な9のアルゴリズム」「CleanCoder」「戦うプログラマー」 の本に書いてあるじゃん。馬鹿にしてるのか？
２年半ほど経ちますが、空前のNTT退職ブームなので便乗しちゃいます。
まず既知の通りNTTグループは社員数約２８万人と非常に大きな組織であり、その中で研究所はエリート中のエリートが就く位置にある。つまり上記の方達は警察でいえばキャリア組にあたる方達にあたる。以降キャリア組と呼ばせていただく。
一方で、私は地方のノンキャリア警察官のようなポジションにある子会社（大株主は研究所）出身なので、その分際でこのようなエントリーを書くのはおこがましいかもしれないが、
キャリア組層のエントリーなのに共感できる部分がとても多い上に、すでに [10年勤めたNTTを退職しました（無能編）https://anond.hatelabo.jp/20181126192228 ]のようなノンキャリアそうな人（←失礼はご愛嬌）のエントリーもあったりしたのでちゃっかり便乗させてもらう。
データとデー子もこんな感じなのだろうか。ぜひ知りたいものだ。
やったぜ。 投稿者：変態IoT土方 (11月23日（月）19時47分42秒)
昨日の11月22日にいつもの組み込みエンジニアのおっさん（34歳）と先日DMくれた機械学習好きのPythonエンジニアのにいちゃん
(27歳)とわし（30歳）の3人で県北にあるコワーキングスペースで開発しあったぜ。
今日は明日が休みなんでコンビニでRedBullとお菓子を買ってから滅多に人が来ない所なんで、
そこでしこたまRedBullを飲んでから開発しはじめたんや。
3人でGithubのコード眺めあいながらTシャツだけになり持って来たRasberry Pi3台にコードをインストールした。
しばらくしたら、EthernetのLEDがピカピカして来るし、ログが解析基盤を求めてS3の中でぐるぐるしている。
組み込みエンジニアのおっさんにセンサーデータ取得コードをデバッグさせながら、兄ちゃんの実装した分類アルゴリズムを眺めてたら、先に兄ちゃんのRasPyがわしのDBにログをドバーっと出して来た。
それと同時におっさんもわしもコードをpushしたんや。もうDB中、ログまみれや、
3人で出したログをfluentdで掬いながらお互いのコードをレビューしあったり、
欠損値まみれの時系列を取得しあってDNNで学習したりした。ああ～～たまらねえぜ。
しばらく学習しまくってから又cross validationをしあうともう気が狂う程気持ちええんじゃ。
組み込みエンジニアのおっさんのRasPyにわしの切ったブランチのコードを突うインストールっでやると
DB経由で取得したログをPythonでするする解析できて気持ちが良い。
にいちゃんもおっさんのRasPyにコード突っ込んでC++ をつかって居る。
ログまみれのおっさんのDBを掻きながら、思い切り解析したんや。
それからは、もうめちゃくちゃにおっさんと兄ちゃんのコードをレビューしあい、
プルリクを送りあい、二回も修正を出した。もう一度やりたいぜ。
やはり実機でデータまみれになると最高やで。こんな、変態親父とデータサイエンスあそびしないか。
ああ～～早くデータまみれになろうぜ。
岡山の県北であえる奴なら最高や。わしは@__hentai_IoT,おっさんは@IoT_kumikomi_ossann、や
