  |
はてなキーワード: SSMとは
7年半を振り返ったのでメモ
WS-20エンジンも量産が始まり、中国軍の航空機エンジンの国産化はヘリなども含めてほぼ完了したと見て良さそうだ。
中国軍は、第3次台湾海峡危機の際に米海軍空母を前になす術がなかったという屈辱を糧に軍の近代化に励んできました。
今や中国軍は1996年当時とは比較にならないほど近代化されており、針ネズミのように配備されたミサイル群は、米空母でさえ迂闊に近付けば撃沈されかねない。
中国空母の直援艦は全部中華イージスになりましたね(別動で054A型はいますが)。
今や中華イージスの就役数は、055型6隻、052D型24隻、052C型6隻の36隻まで増えている。
052D型と055型は10年前には1隻も就役していなかった。
055 ×16
052D ×37
052C ×6
051C ×2
052B ×2
ソブレメンヌイ級 ×4
051B ×1
中国海軍2012年からの8年だけで以下の艦艇が進水してますからね、規格外の拡張と言って良い。
002型空母 1隻
075型強襲揚陸艦 3隻
055型駆逐艦 8隻
052D型駆逐艦 25隻
056型コルベット 72隻
渤海造船所に新設された世界最大規模の潜水艦建造施設で、初の建造中の原潜が確認されました。
存在が噂されてきた093B型、095型攻撃型原潜もしくは、096型戦略原潜である可能性が高い模様。
J-10CやJ-20もWS-10エンジンに切り替わったので中国の戦闘機エンジンの国産化は成功したと言えそうですね。
ただ、輸送機や爆撃機向けのWS-18やWS-20はまだ量産されておらず、中国軍用機のロシアからの自立はまだかかりそうです。
2000年代初頭に052B型、051C型、052C型、956EM型を2隻ずつ建造して、技術的に成熟してから大量建造に移行したというのは多少知識がある方なら知っているでしょうが、表にしてみると分かりやすいかと思います。
大連造船所で052DL型駆逐艦23番艦と055型駆逐艦6番艦が進水。
ひとつの国が1年間で駆逐艦を9隻進水させたのは1946年以来、73年ぶりです
駆逐艦工場と化している大連造船所と上海江南造船所について。1年間に最大で8隻の駆逐艦を進水させる能力があります。
jbbs.shitaraba.net/bbs/read.cgi/sports/37992/1533086155/963
中国の空母建造地である江南造船廠と大連造船廠は、どちらもドックの拡張や新ドックの建設、建造能力の強化を図っている。これは空母および護衛艦である055型駆逐艦の量産体制の確立を目指すものと見ている
＞大連ではこの拡張工事が終われば、空母二隻の平行建造、そして055型五隻の同時建造が可能になると推測している。江南造船廠では、現在建造中の003型空母のために新たな船台を建設している。
＞漢和では、今後両造船所が複数空母を並行して建造する可能性を示すものとして注目している
国産エンジンを搭載したJ-10CとJ-20の生産が始まり、戦闘機のエンジンをロシアに依存していた時代がいよいよ終わると。
jbbs.shitaraba.net/bbs/read.cgi/sports/37992/1533086155/783
＞大連に到着したワリヤーグは海軍技術陣による調査を受け、主船体の状態は良好で船体の腐蝕も少なく新造船に近い状態で、今後40～50年間は問題ないと評価
＞完成度は40%と判断し、建造を続行し就役させるための基礎には十分であると判断
＞建造作業は2004年8月13日に着手。そこで遭遇したのは予想以上の困難であった。一つの例を挙げると、ワリヤーグの設計段階ではSu-33の制式化前だったので予定スペックに基づいた格納庫設計が為されていたことが判明した
＞設計作業ではSu-33の折り畳み状態での翼幅は7.4mであるとして設計されていたがこれは実際には8.4mになっていた。Su-33の情報をもとに開発されたJ-15も折り畳み状態の翼幅は8.4mになるので、格納庫はそれに合わせた設計変更を余儀なくされた
＞改装作業では、甲板や格納庫の調整、船体構造の設計合理化、失われたパイプ系統などの配置と各種方面で元々の設計の問題点があれば設計変更や換装を行っていった
＞アレスティングワイヤを含む着艦拘束システムについても国内開発されたものが搭載
＞全長65mに及ぶ艦橋があったが、それでも各種アンテナ、通信機器、電子戦装備を電子干渉を起こさずに搭載するには不十分
＞ホイップ状の倒立アンテナを開発し、舷側の各部に配置することでこの問題を解決した。以後の空母では、中国のアンテナ集積技術の発展に伴い、アイランドの形状は簡潔化
＞遼寧は2004年の再生工事着工から、8年の時間をかけて2012年9月25日に制式に部隊配備
＞遼寧は、艦内のSSM用VLSを撤去して格納庫を拡大したのではないかと推測されてきましたが、最近になって面積拡大はなされていないという結論に達しています
＞36機の搭載機数は6万トン級空母としては少ないと指摘されていますが、無理に搭載機を増やしてもSTOBAR式空母である遼寧ではその数を有効活用するには問題があり、36機というのが最も合理的な数字であるとなったのはよく理解できる話です
(終わり)
アメリカで空母を作れるのはニューポート・ニューズ造船所だけですが、中国は上海と大連の2ヶ所で建造可能なのですよね。
質問なんですけど中国って軍艦や大型船建造のドックがある造船所ってどれぐらいあるんでしょうか
＞中国の主な造船所
＞2、江南造船所（上海長興島）：駆逐艦、空母、揚陸艦、通常動力型潜水艦、掃海艦など
＞4、中華造船所（上海浦東）：フリゲート、コルベット、揚陸艦、偵察艦、補給艦など
＞5、黄埔造船所（広東広州）：フリゲート、コルベット、公務船など
＞6、武昌造船所（湖北武漢）：コルベット、通常動力型潜水艦など
中国は8個の大型造船所を保持してて、空母建造可能造船所が2個ある・・・
やっぱ劉華清のおかげやな（造船所強化にも力を注いでたし）
中国の渤海造船所で建設されていた世界最大の原子力潜水艦建造施設はほぼ完成したようです
jbbs.shitaraba.net/bbs/read.cgi/sports/37992/1533086155/706
＞大連と長興島だけで、055型6～7隻、052D/E型16隻＋6を建造/建造中
＞全世界に展開する米海軍に対し、中国は全艦艇を自国海域に投入できる点で有利であり、艦艇間の性能差もそこまで大きなものではなくなってきている
＞空母艦隊の戦力、経験の蓄積、戦闘機や原潜の数や質、ASW能力の差などの面で、中国海軍が追い付いていない点も多い
＞055型はアーレイ・バーク級を上回る戦闘力を備え、米タイコンデロガ級巡洋艦に近い立ち位置の艦。055型の増勢に対して米海軍のタイコンデロガ級は段階的に退役が進む
＞今後10年以内に、大型水上戦闘艦艇の数で対米5割に達することは充分に考えられる
＞11隻の空母を要する米海軍に対し、中国海軍は陸上航空機や弾道ミサイルの支援を受けることが可能な海域で対峙することになろう
＞西太平洋での台湾有事など局地戦勃発に際して、台湾東岸を封鎖して、展開する米空母部隊に対峙する能力を獲得することになる。このほか、空母戦闘群を世界各地に展開し、洋上航路の安全や海域の封鎖、邦人保護や陸上施設の打撃など多様な任務に投入されることになろう。
＞その際には、YJ-18巡航ミサイルの艦対地型による内陸打撃も想定される。2019年以降、水上艦艇の建造と並行して攻撃型原潜の大量建造も進められることになる。
渤海造船所に新設された世界最大の原子力潜水艦建造工場がすでに稼働しているらしい。同時に6隻が建造可能。
中国のジェットエンジンが世界水準から立ち遅れを生じた理由について、北京航空航天大学の劉大響教授の見解
jbbs.shitaraba.net/bbs/read.cgi/sports/37992/1533086155/566
＞国家経済の相対的立ち遅れにより、研究開発費がはなはだしく不足していた(続く)
＞開発リソースに対して、開発の規模が大きすぎ、リソースが分散し、低レベルでの重複が生じた
＞管理モデルが時代遅れで、科学・民主的な政策決定機構と安定性に乏しく、権威ある中長期的な発展計画が欠けていた
＞アメリカを例にとり、IHPTETやVAATEなどの予備研究に数百億ドルを投じたこと、両国の技術格差を示すものとして、F119エンジンの寿命が12,000時間に達するのに対して、WS-10は1,500時間に留まることを指摘、この差が生じる主な原因としては素材の高温環境における耐久性にあるとした
＞中国のエンジン開発は、模倣―改造―自主開発と段階を経ており、2016年8月には中国航空発動機集団が成立し、「両機専項（ジェットエンジンとガスタービン事業）」が始動しており、中国の航空機エンジン開発は新段階に入った事を示す事例であるとしている
jbbs.shitaraba.net/bbs/read.cgi/sports/37992/1533086155/458
＞052C型は「型號H/ZBJ-1」システムを初めて搭載。同システムは、高い自動性を有した先進的な戦場管理システムであり、この開発成功により中国は初めて「真のエリアディフェンス防空システム」を獲得(続く)
＞052D型は052C型をベースに「プラットフォーム共通化、装備のモジュール化」を進め、防空能力を含む多用途性能改善を図ったタイプ。作戦システムは、先進国艦艇で採用される分散・開放式を取り入れており、高い分析処理能力を有すると共に、将来のアップグレードや新装備との統合も容易に行える
＞米Link-16に相当する的「全軍綜合數據鏈系統(「聯合網路作戰系統」)」データリンクシステムを搭載しており、各軍種を超える情報連携を実現
＞VLSが各種ミサイルの混載を可能とするタイプに変わったことも見逃せない
＞055型駆逐艦は、抜本的に設計を改めた新型駆逐艦として開発された。これは米海軍がアーレイ・バーク級駆逐艦の改良を続けているのとは対照的
＞055型の特徴は①COGAG機関の採用、②デュアルバンドフェイズド・アレイ・レーダーの採用、③統合マストの採用、④112セルのVLS搭載、にあると指摘
＞055型は、中国海軍の駆逐艦能力を世界でもトップレベルに高めた画期的なものと評価。その能力や技術水準は米ズムウォルト級駆逐艦と比較しても遜色なく、優位に立つ所もあるとする。米専門家の「嘆息美國難以追趕（嘆息して、アメリカも追いかけるのは難しい）」というセリフを引用
＞055型の発展潜在性は高く、今後は、統合電気推進システムの採用、電磁砲搭載などさらなる改良が施されるであろう
＞055型は中国海軍の外洋化を象徴する兵器であり、台湾側への圧力はさらに増すことになり、厳重な警戒と深い分析が必要であるとまとめている
今年進水した中国海軍水上戦闘艦は駆逐艦6隻、フリゲート1隻、コルベット10隻、合計17隻。これはとんでもないペースですよ。
中国海軍は、052D型×22、055型×8の計30隻の中華イージス艦を建造しているようだ。052C型を合わせると中華イージスは36隻。
近代的な駆逐艦の総数は、052A型×2、051B型×1、現代級×2、052B型×2、051C型×2の計9隻を合わせた45隻になる。
かつて中国海軍は、2隻新型艦を建造して試験した後、さらなる新型艦2隻を建造するという工程(小歩快跑と呼ばれた)を繰り返して技術力の向上に勤め、052D型駆逐艦からようやく大量建造に踏み切りました。彼らは自分達の技術レベルを理解した上で相当先まで見据えて事を進めているんですよ。
上海江南造船所の空撮映像(別角度)。海上自衛隊が10年くらいかけて建造した数の艦を１つの造船所で同時に建造している。凄まじい光景ですね。しかも、大連など他の造船所でも大量に作っているのだから・・・。
江南造船所
・055型駆逐艦 ×3
・052D型駆逐艦 ×6
大連造船所
・055型駆逐艦 ×3
・052D型駆逐艦 ×5
002型空母 ×1
055型駆逐艦 ×6
合計 ×27
--
この本は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%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
お偉いさんを多数迎え、社会調査により大勢の職業人生を破壊し続ける巨悪・職業威信の調査と比べたら屁のようなものだ。
前回のSSM調査では権力者を集めすぎて失敗ぎみになったからよかったものの、次回の調査ではどうなってしまうのか。
道路工事員の待遇改善は止まり、清掃員の地位向上の働きかけはなくなってしまうことだろう。
そして、調査する側は今回のように言うのだ。「状況を明らかにしただけだ。手続き上は何の問題もない。」と。
この職業コミュニティの破壊をとめるためには一刻も早く自称社会学者なる社会破壊活動者の活動をとめる必要がある。
