  |
はてなキーワード: 設定ファイルとは
ブログやIT技術者向けSNS等は利用しておらず、はてブやTwitterでやるにはやや長いので、増田に投稿
Windows 10 (22H2 19045.4170) 上のEdgeを、数十のタブを開いたまま新バージョン (123.0.2420.53) に更新したらハングアップしたため、タスクマネージャーで強制終了させた
その後Edgeを起動させようとすると、更新時に閉じたセッションを復帰させる段階で強制終了するようになり、使用不能になった
Edgeに導入していた拡張機能には、Session Budy (4.0.2。GoogleのManifest V3に対応するため、最近大規模改修を実施(1。増田の最終節の同番号を参照。以下同)) やuBlock Origin (1.56.0。新規のマイフィルターを多数追加中だった) 等があった
「Edgeが起動しない」と直截な語句で検索していくつかの解説ページにたどり着いた
いくつかの解決策(2・3)を実行したところ、有効ではなかったが次の知見が得られた
数日程度では修復できないだろうと判断し、別のChromiumブラウザを使いつつ、片手間で修復方法を調べることにした
Windowsの設定画面等にあるリンクが有効になるよう、デフォルトのwebブラウザをEdgeから変更した
パスワードは別ツールで管理してたため無くてもそんなに困らなかったが、uBlockの設定とSession Budyで雑に保存してた閲覧履歴は必要だったので、Chrome拡張の復旧作業をした
"Default\Local Extension Settings"以下のフォルダと、念のために"Default\IndexedDB""Default\Local Storage\leveldb"の中身を移植(8)して作業完了
アイテムの履歴データ破損が問題の原因ではと考えてその修復や初期化方法を検索したが、これは徒労に終わった（ただし、このアプローチが完全に無効だとは言い切れない。参考ページ5は、復旧作業完了後に見つけた情報で、今回の問題に活用できずに終わった）
「コントロールパネル→システムとセキュリティ→セキュリティとメンテナンス→信頼性履歴の表示→問題レポートをすべて表示」で確認できた、Edgeの問題の要約やイベント名等で検索したところ、再インストールを勧めるページが数点引っかかった
既に何日も経ちWindowsの再インストールかユーザーアカウントの作り直しをしようかと考えかけていたが、もう少し努力してみることにした
Edgeを (アプリファイルを手動で削除したりするのではなく) なるべく安全にアンインストールすれば、正常に再インストールできるのではと考え、検索結果通り(11・12)に作業してみた
それでも「アプリ」のアンインストールメニューは無効なままで操作できなかったが、他に事例が無いか、"IntegratedServicesRegionPolicySet.json"等の関連語句で再検索した
コマンドラインでアンインストールを試みた事例(13)が見つかり、実行したらEdgeが削除された (ただし、コマンドプロンプトでもポップアップウィンドウでも実行結果の表示がされなかった)
そして参考ページ4のインストーラを実行し、念のために修復とOSの再起動をかけ、Edgeの起動を確認した
Microsoftアカウントにログインしていたため、パスワードは簡単に復旧できた
拡張機能は全て死んでいたが、仮に使っていたChromiumブラウザからコピペしたりエクスポートしたりして終了
利用していた拡張が少なかったので、プロファイルフォルダの内容の移植よりもその方が簡単だった
1. SESSION BUDDY V3 END OF LIFE | Google グループ
https://groups.google.com/g/sessionbuddy-discuss/c/HQPcLOq3-Ik
2. Microsoft Edgeが直ぐ閉じてしまう。 | Microsoft コミュニティ
https://answers.microsoft.com/ja-jp/microsoftedge/forum/all/microsoft/c414d2f9-b685-471c-8e78-2054c2e26c6c
3. ある日突然「Microsoft Edge」が開かなくなった、さあどうしましょう：山市良のうぃんどうず日記（224） | ＠IT
https://atmarkit.itmedia.co.jp/ait/articles/2202/02/news009.html
https://www.microsoft.com/ja-jp/edge/download?form=MA13FJ
5. Windows10の「タスクバーにピン留めしているアプリ」の、「最近使ったもの」と「固定済み(いつも表示)」の設定ファイルとレジストリはここにある #Windows10 | Qiita
https://qiita.com/RyoIchimura/items/7e33980358f07e57a715
6. msconfig（システム構成）で解除してよいのは？使用場面と起動方法 | ドスパラ通販【公式】
https://www.dospara.co.jp/5info/cts_str_pc_msconfig.html
7. Windows Hello の概要とセットアップ | Microsoft サポート
https://support.microsoft.com/ja-jp/windows/windows-hello-%E3%81%AE%E6%A6%82%E8%A6%81%E3%81%A8%E3%82%BB%E3%83%83%E3%83%88%E3%82%A2%E3%83%83%E3%83%97-dae28983-8242-bb2a-d3d1-87c9d265a5f0
8. chrome.storageの実体の場所 #Chrome | Qiita
https://qiita.com/k7a/items/cf644471d34d31f398e9
9. 第2回 グループ・ポリシーとは何か：グループ・ポリシーのしくみ（3/5 ページ） | ＠IT
https://atmarkit.itmedia.co.jp/ait/articles/0602/23/news119_3.html
10. Microsoft Edge ブラウザー ポリシーに関するドキュメント | Microsoft Learn
https://learn.microsoft.com/ja-jp/deployedge/microsoft-edge-policies
11. Windows 11/10からMicrosoft Edgeをアンインストールするシンプルな方法が見つかる | ソフトアンテナ
https://softantenna.com/blog/windows-11-10-uninstall-edge/
12. Releases · thebookisclosed/ViVe | GitHub
https://github.com/thebookisclosed/ViVe/releases
13. 各チャネルごとの Edge 削除状況 | 内気なもんた君
稟議書を作成して外部ファイル名の採番をライブラリアンに依頼する。稟議にはPL、PM、CIOの承認印が必要
本番サーバーに新規ファイルを作成する必要がある。ファイル作成バッチを作成しレビューを受ける必要がある。
本番サーバーは高セキュリティエリアにあるため入室申請が必要。
外部ファイルのメンテナンスはサバ管部門が行うため、消えてしまった場合、不正な値が設定された場合のリカバリ手順を作成し、サバ管部門の承認を受ける必要がある。
上記すべての手順について、役員の最終認証を得るためにレビュー会を実施するひつようがある。
この業務の処理手順は、数年ごとに多少の変更が入り、今回も、その対応が彼の仕事だった。
彼が、前任者が作ったソースを開いてみると、それはごく単純に業務手順書をプログラムに置き換えたようなもので、
固定値がそのまま文中に記述(マジックナンバー)されていたり、お世辞にも格好いいとは言えないものだった。
彼は考えた。「数年ごとに変更があるのがわかってるんだから、もっと変更に柔軟に対応できるようにしておくべきだ！」
そこで彼は、様々な決まり事や数値を一切固定で埋め込まず、あらゆる項目を外部の設定ファイルで変更できるようにした。
プログラムは完成し、彼は運用者と次の後任者に自信満々で言った。
「今後は、業務手順に変更があっても、プログラムをビルドし直す必要はありませんよ！設定ファイルで設定を変えるだけでOKです！」
さて、その数年後、実際に業務手順に変更があった。
運用者は設定ファイルを変更したが、うまく正しい結果が出ない。
バグが出てしまったか？と、後任者はソースを開いてみて愕然とした。
そこにあったのは、様々な設定項目に対応するための、膨大なif文ブロックの塊だった。
ソースの大半は、「将来的にこの設定が変更されたら」に対応するための、使われていない行。
設定の組み合わせパターンは膨大になり、全ての分岐カバーテストはされてはいなかったのだ。
再び、現在の業務手順だけを、そのまんまプログラムに落とし込んでいった。
確かにこの方法では、業務手順変更がある度に、プログラムを直してビルドする必要があるが、
そもそもプログラム言語というものは、「手順を明快に記述できる」ように発達してきたものなので、
手順書そのもののようなその新しいプログラムは、誰でも簡単に理解して修正できるものになっていた。
【教訓】将来の変更に対応するための「汎用性」「柔軟性」を上げようとするのは間違っていないが、
実際に来るかもわからない将来に備えてプログラムを複雑化するのは間違い。
PC・スマホ・タブレット等のIT機器のヘルプ対応をしているけど、このうち対応が最も面倒なのがLinux。
Windowsやmacよりも件数はかなり少ない代わりに、対応の難易度の高さは飛び抜けている。
それもうオンサイト対応じゃなきゃ解決できねーよみたいな内容が極端に多い。
どういう使い方で、どんなソフトウェアをどのように入れたかにより、OSの奥深くにある基本的な設定が書き換わるケースもあるし、もちろんディストリビューションやバージョンごとの違いもあるしで、
設定ファイルの修正方法やコマンドを送ったくらいでは解決せず、挙げ句
「このコマンドを実行してください」
というやりとりが延々続くだけになり、手に負えなくなってサポート打ち切りになるケースがほとんど。
というかサーバじゃなくデスクトップで使っているなら、そしてそんなとこまでこっちにやらせるなら今すぐフォーマットしてWindows入れろやボケ！！！
と言ってやりたくなる。
なんでこう、Linuxのトラブルはどいつもこいつもやたらややこしいんだか。
正直Linuxのヘルプ対応をするたび、Linuxがどんどん嫌いになっていく。
(追記)
サポートってどんなサポート？という質問があったけど、本当にごく普通のクライアントPCのトラブル対応を、いわゆる情シスのスタッフとしてやっている。
ちな会社は社員数1万人くらいで、自分はそこの情シスの中の、本社の社員のIT機器をサポートするチームのメンバー。
とはいえ対応時に見ているのは社員のPCだけじゃなく、場合によってはその社員が接続した際のDHCPやDNS、FWのログはもちろん、L2・L3スイッチやRADIUSだって見に行く。
それでもトラブルの原因がわからないときがあるので、ネットワークのチームやサーバのチームに相談することもしょっちゅう。
なお自分はもともと、開発・構築・運用と使い回されてきたタイプで、開発一つ取ってもWindowsアプリにiPadアプリにWeb系にとこなしてきた。
あとデスクトップLinuxは大学いた頃に慣れ親しんでいた(レポートや論文を書くくらいには使っていた)。
で、そんな君みたいな人を待っていたんだ！と言われ引き抜かれたのが今の仕事というわけ。
ただLinuxのサポートにここまで手こずるのは想定外だったわ。
やはり専門知識という意味ではLPICくらいは取ったほうがいいのか？と思っていたり。
(追追記)
ウチの会社でデスクトップLinuxを使っているのは(macもだけど)主にR＆D部門と、そこから転属or昇進した人達。
(一方でバックオフィス系は、サポートが最も楽なリース契約のWindowsPCだったりする)
このうち問い合わせてくるのは、大体が
のどちらかで、このうち後者については部門のガバナンスどうなってんだと思わなくもない。
「それもう試した」
→どこまで何を確認したか要点だけでも教えてくださいよ…このやり取り、普通に時間の無駄ですよね？
「ありませんでした」
→「ありませんでした」じゃねえ探すんだよ！ログがなきゃ原因特定できないんだが？そんなこともわからないでLinux使ってるのかよ…。
9x→XP（2k）で動かなくなったアプリが多々あったのは確かだけど、それはファイルアクセスの権限の問題というよりは、アプリがパフォーマンス最重視で設計されていたりレガシーコードが悪さしたりして古いシステムコールを多用してたのが原因だったのではないかなと思う（起動した瞬間にハングアウトしたり画面が化けたりするゲームがあったことを覚えている）
XPSP2でファイアウォールがOSのデフォルト機能として搭載されたけど、それはアプリのインターネットアクセスを規制するためのもので管理者権限での実行を制約するものではなかったはず
一昨年の末、某WEBサービスの運営者として前任者逃亡状態で入社した
管理画面から設定を行い、サイト内の所定の場所に広告を表示させる
広告によって性別とか年齢で送信先を絞ったり、地域によって掲載内容を変えたりと細かい指定が入る
しかし前任者がマニュアルも残していかなかったので、この振り分けができなかった
管理画面のどこにもその項目がないのだ
おそらくサーバー上のどこかに設定ファイルか何かを置いていたんだと思うが、
上司に状況を説明したかったが、上司は「アウトルックって何？」というタイプの人間だった
というか社員全員そういうおじさんだった
わかる人間はすでに全員逃げていたのだ
社内全体で状況を共有して対処すべきだったが、説明が死ぬほど面倒だった
「引き継ぎ不足で、現状指定されたセグメントに配信するのが困難です。ですので当面の間、可能な範囲で広告主の要望に近い絞り込みを行って配信して、要望通りに配信していることにしませんか。苦肉の策ということで。もちろん平行して解析を進め、早急に従来どおりの配信を再開できるように努めます」
ということをもうちょっとそれっぽく言い、「じゃあ、それでいこう」と了承を得た
ちなみに「可能な範囲で」とは言ったが、可能なことはなにもないので俺はすべての広告を全会員にむけて投げ続けた
嘘は言ってないよな
全員に送ってるわけだからはじめの頃は反響も大きく、広告主からも高評価だった
まあ同じサービスから一日何通も広告メールが飛んできたらそうなるよな
メルマガ会員数も急激に減少の一途を辿ったが、俺はそれを誰にも報告しなかった
そして引き続き全ての広告を全員に投げ続けた
そのうち客からも効果が合わないと怒られるようになり、補填としてさらに配信回数を増やした。
これにより眠っていた潜在ユーザーも退会していき、ついに広告収入モデルは崩壊した
効果の薄い広告メールを大量に配信するだけのゾンビとなった某WEBサービスはそれから半年弱の間赤字を積み上げながら生存したが、ついに立ち行かなくなり倒産が決まった
とても感慨深かった
社長は俺に対して何度も何度も謝ってくれた
「安い給料で1人でずっと頑張ってくれたのに、持ちこたえられなくてごめんな」と
いや。AWSだとLinuxやネットワーク周りの知識が不用になるってことは別にないけどってだけ
ただ、オンプレのLinuxが主流の時代ならみんな理解してたのか？と言えば別にそんなことは無いです
オンプレのLinuxが主流の時代でも仕組みをよくわかっていない人によって動いてるサーバーはたくさんあった
そもそも学習目的以外でゼロからカーネルや設定ファイル弄ってサーバー構築とかなかったです
サーバーエンジニア・ネットワークエンジニア・セキュリティエンジニア・社内インフラ担当(社内SE)呼称はなんでも良いが
彼らの作った設定をコピペやぞ(ひどい場合は技術blogからコピペ)
★★再追記
レンタルサーバは、自由度が低くてストレスになるからやらない。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円くらい払ってる。それがなければ月数円。
viエディタと同様、キーボードのみで操作されることを前提としていたため、キーボードのみですべての操作が可能になっている。その基本的な操作方法はviと同じで、状況に応じてモードを使い分けることでテキストを編集していき、小さなコマンドの組み合わせをその場で作ることによって多種多様な機能を実現する。
他のエディタとは操作方法がまるで異なるため、一通りのテキスト編集作業ができるようになるまで慣れが必要となる。しかしながら、一旦慣れてしまえば軽快なテキスト編集ができるため、数多くのVim愛好家が存在する。Vimの他の機能と併せて、プログラムコードやシステム設定ファイルを編集するのに特化しているため、特にプログラマーやシステム管理者に利用者が多い。
なるほど。
そうでなければ少数の職人芸になって、老人の自己満足になってしまう。
vi/vimがほかのエディタよりユーザーが多いのかは知らないけど。
あとは、viはメモリが数十KBの時代に、軽く動くことを想定して作られたってことがキーポイントかもね。
今時軽いからといってWindows2000使う人いないでしょ。
個人的には、慣れてるから使う、古くからあるから使う、ってのは、思考停止のアホに見える。
そういうのはITじゃなくて土方行ったほうがいい。
前提として、サーバ側のDBの中身が漏洩したと同時に、プログラム、設定ファイル、丸ごと全部漏洩したとみなしている。
プログラムがDB上のパスワードをどのように処理してるか丸見えになる。
複合できるということは、プログラムの手の届く場所に鍵があるということ。
その鍵がユーザごとに違っていようが関係ない。そのプログラムを通せば複合できるわけだから。
複合した結果、元のパスワードを「瞬時に」出せる。
その元のパスワードを使って、正規のユーザのフリをして悪いことができる。
さてハッシュの場合、bcryptなどではソルト付きハッシュ値になってる。
ハッシュなので「時間をかければ」、そのハッシュ値になる値を検索できる。
元のパスワードと同一であるかどうかはわからない。（同一でなければバレる可能性が高まる）
ここである程度時間を稼げるので、サーバ管理者側にサービスを停止したり、パスワードを全部向こうにするような時間の余裕ができる
--
この本は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%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
