  |
はてなキーワード: パイプラインとは
増産するだけは草
［ベルリン ２７日 ロイター］ - ドイツのショルツ首相は２７日、ロシアのウクライナ侵攻を受けて、ロシア産ガスへの依存度を引き下げるためにエネルギー政策を大きく転換する方針を示した。ウクライナ危機に対処するため開かれた臨時国会で表明した。石炭火力発電所と原子力発電所の運用期限を延長する可能性がある。
２月２７日、ドイツのショルツ首相はロシアのウクライナ侵攻を受けて、ロシア産ガスへの依存度を引き下げるためにエネルギー政策を大きく転換する方針を示した。写真は２００７年４月、ドイツのハノーバーで行われた産業見本市で、天然ガス輸送パイプライン「ノルドストリーム」の展示を清掃する女性（２０２２年 ロイター／Christian Charisius）
ドイツは他の西側諸国からロシア産ガスへの依存度を引き下げるよう求める圧力を受けているが、石炭火力発電所を２０３０年までに段階的に廃止し、原子力発電所を今年末までに閉鎖する計画では、ほとんど選択肢がない状態となっている。
Reuters Graphic
ショルツ氏は「ここ数日の動きにより、責任ある、先を見据えたエネルギー政策が、わが国の経済と環境のみならず、安全保障のためにも決定的に重要であることが明らかになった」と指摘。「わが国は個別のエネルギー供給国からの輸入に依存している状況を克服するため、方針を転換しなければならない」と訴えた。
新たな方針には、ブルンスビュッテルとビルヘルムスハーフェンの２カ所に液化天然ガス（ＬＮＧ）ターミナルを建設する計画が盛り込まれている。
ショルツ氏によると、天然ガス備蓄施設の容量を長期的に２０億立方メートル増やし、欧州連合（ＥＵ）と協力して天然ガスを世界市場で追加購入する。
またハーベック経済・気候保護相（緑の党）は、同国のエネルギー供給を確保する手法として、現在も稼働している原子力発電所の運転期限延長を検討していると明らかにした。
ハーベック氏は既存原発の運転延長を認めるかとの質問に対して、「その質問に答えるのはわが省の任務であり、考え方は否定しない」と語った。
そもそもyoutube動画って時点でソースもない言いっぱなしってことだから無視してたけども、パイプラインぐらいタンカーで運べばいいだけ。それをあたかも大事化のように。値段がちょっと安くなってただけ。問題は、国際社会がインフレに耐える覚悟があるか。
この後どうなるのかは分からないけれど、キエフの陥落は1日後か2日後か数時間後か避けられないでしょう
ウクライナにとって非武装化の和平は受け入れられないから、和平交渉開始してもキエフ陥落で終わるとも思えない
それにウクライナには今はまだ出来ない奥の手が残ってる
いざとなればウクライナを横断するパイプラインを、ウクライナ西側の出口で破壊してやればいい
西側も困るウクライナも困る、だがノルドストームⅡが動かない今はロシアには致命的な傷になる
殺されるのなら殺してやればいいという奥の手がまだ残ってるし、切羽詰まったら西側は批判できないでしょう
ロシアだって分かってるから、川の西側までは踏み込みたくないだろうね
そうこうしてるうちに、ウクライナ西部を睨む西側の軍事的・経済的・外交的支援はより手厚くなりロシアは身動き取れなくなってしまうだろう
なんか俺より賢い人が多いはずのはてブ見てると、アメリカがロシアの先手打って情報出してロシアの動きを牽制してる！みたいなこと言うアメリカベタ褒めのブクマカいっぱいおるし、ロシア関連のニュースのブクマに沸いて星集めてるけどさ。
アメリカの今の情報の出し方は、ロシアがどう動いても国際社会での地位を失うように、何もせずに勝負を降りれないようにレイズしまくってるだけだろ。
ネオコンがどうこうみたいな話は流石に陰謀論じみてるけど、軍需産業からのロビー活動がある中、レームダックを打開したいバイデンが、ウクライナっつーちょうどいいテーブル見つけて博打打ってるって話なんでねーの？
トランプの時ならいざ知らず、今のアメリカが戦争したくないとか、どこの国の話してんの？って思うんだけど。
ロシアもソ連のころの失地回復的とかガスのパイプラインとかその辺の動機で動くのかもしれないけど(穀倉地帯だからみたいなのは、温暖化で農業限界地域がどんどん減ってるロシアにはあんま重要じゃなくね？って気もする)同じぐらいアメリカにも戦争したい動機あるんじゃないの？って思うんだが。
--
この本は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%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
パイプラインって言うんですけど、そのパイプラインの段数をある程度までは増やしたほうがスループット上がるんですよね。それと同じです。
例えばコンビニでは：
会計待ち行列スペース → カウンター（店員がバーコード読み・客が支払い機で支払う・店員が袋詰め）
っていう２スペースしかないんですけど、
スペースが空くまで待ってる人は先へ進めないわけです。
会計待ち行列スペース → カウンターで店員がバーコード読み → 客が支払い機へ移動して支払う → 客が袋詰めスペースへ移動して袋詰め
客がカウンターから支払機へ移動した時点で、待ち行列の次の人間がカウンターへ進めるわけです。
場所を取って作業段階を細分化することで、後ろで待ってる人がどんどん先の作業へ進めるわけです。
所要時間を
バーコード読み１０秒
支払い１０秒
袋詰め１０秒
と仮定すると、
待ってる人が２人いる場合、
コンビニでは10x3=30秒かけてやっと1人が終わってカウンターが空いて2人目をやるので、60秒かかります。
センターピボットと言われても分からない人もいるかもしれないが、要は『円形の農地の中央にスプリンクラーを置いて灌漑するやつ』である。アメリカや中国の乾燥地帯などではこの方法を用いて大規模な穀物生産をしている。
このやり方、水効率は確かに良い。が、水の出所は多くの場合地下水であり、地下水は限られた資源だ。一方で灌漑に用いられた水は一部は植物に取り込まれ、一部は蒸発し、一部は地下に還っていく。
つまり、センターピボットによる農業を続けている限り地下水が減少していくのであり、大規模なセンターピボットを行っている地域で地下水が尽きたら農業生産が大きく落ち込む。明らかに持続的ではない。
もちろん、「だから今すぐセンターピボットを止めろ。穀物の価格が上がって貧乏人が餓死しても知ったことか」などと言うつもりはない。が、今のうちに持続可能なものにする必要はあるだろう。
蕨変電所の火災でJR線が止まってる問題だが、これは直ぐには復旧できない。恐らく世の人が思っている以上に大きな事故なんである。
何故なら蕨変電所は普通の変電所と違ってハブになる変電所なので東京の1/3の路線に送電できなくなるからなのだ。
その影響は過去の事例から見て不通の解消に１日程度、つまり明日の朝は東京北部のJR線は走らないと考える。
そしてダイヤの大幅な乱れや並行私鉄線の殺人的な混雑は１週間程度続くと思われる。
まず、送電というのは発電所--変電所--変電所--変圧器（電柱の上）--家 となってるのだが、鉄道の場合はちょっと違う。電車が直流で走るからだ（関東以西）。
電力会社の変電所--鉄道会社の直流変電所（ここで交流→直流化する）--架線
国鉄はコストダウンの為に大需要地である東京での電力の自家調達に努めた。因みに見る角度で本数が変わる「千住のお化け煙突」っていうのは千住の国鉄石炭火力発電所の事だったのよ。
それが
・川崎火力発電所（火力/ガスタービン式、燃料はパイプライン供給の天然ガス/鶴見線扇町駅近く）
・信濃川発電所--武蔵境交流発電所（中央線武蔵境駅近くで見える巨大変電所）--沢山の直流発電所--架線
・川崎火力発電所--鶴見交流変電所（湘南新宿ラインで東海道線から分かれて直ぐに見える巨大変電所）--沢山の直流発電所--架線
となっている。そしてもう一つが今回問題の蕨で
・東京電力（パワーグリッド）鳩ケ谷変電所（岩槻街道沿いの超巨大変電所）--JR蕨交流変電所（蕨-西川口間にあるが少し線路からは離れている）--沢山の直流発電所--架線
となっている。
そして各系統間で電力を融通する為の「連系線」というのが、蕨--武蔵境--鶴見と各交流変電所間にあるんである。蕨交流変電所の隣を電車で通ると「JR蕨」って書いた鉄塔が見えるが、あれが蕨--武蔵境の連系線の鉄塔だ。（東電鳩ケ谷-JR蕨間は地下ケーブル）
因みに福一原発事故で外部交流電源途絶といった時の外部電源はこの連系線の事だよ。
ここで重要なのは、電気は各系統のを混ぜて使うって事は出来ない。
何故なら発電所は交流で位相（+と-が入れ替わる周期）が合っていない。それを「混ぜ」ようとすると打ち消しあって電力が減るし、それ以前にショートと同じだから送電線が爆発する。
だから連系線の電気を使う時は交流変電所から直流変電所への系統ごと切り替えるんだな。
こういう訳なので、架線も直流変電所ごとに区切ってある。その区切りが「エアセクション」ってやつ（架線が変電所系統ごとに平行に張ってある）。よく「エアセクションで電車が止まって立往生」になるのはこういう訳で、変電所毎の区切りをゆっくり進んでしまうとパンタグラフで各系統をショートさせた形になるから過熱して溶けたり燃えたり爆発する訳だ。
ここまで読んでもらったら、蕨交流変電所の復旧が2ステージに分かれる事が判るだろう。
過去に新宿直流変電所が爆発してとんでもない混乱が発生したことがある。山手線が中央線と合流する直前にその間に挟まるように白青の変電所が見えるが、あれが新宿直流変電所。事故以前は小さくてぼろっちい建屋だった。
1994年12月11日は冬の嵐で、多摩地区などでは雷が発生して交通網が混乱していた。そんな中、新宿変電所が漏電により出火。消防隊が臨場したが電気火災なので水を掛ける事ができない。そこでJR社員が遮断しようとしたがもう破壊され尽くしていて不可能。
すると上流の武蔵境交流変電所で遮断するしかありませんな。変電所火災は放っておくと変電器などが破裂して中の絶縁油に引火して大火災になっていきます。
ハブになっている武蔵境で遮断したら当然、東京中の路線も駅も停電して大混乱ですわ。因みにJRの場合は新宿にあるJR病院や本社ビルまで停電しちゃうのな。
それでやっと消火したけど新宿変電所は20万Vで溶接機振り回したような状態で建屋も完全破壊。復旧不可能ですわ。
仕方ないので新宿変電所を切り離す工事をして仮復旧。これで武蔵境から他の変電所に送電できるようになった。これに一日掛かってる。でも電力が足りないので相当な間引き運転で、振替先の私鉄地下鉄各線殺人ラッシュに。
次に新宿が受電してた送電線を他の変電所につなげる分散工事をして復旧。これで普通の運転間隔に戻せた。これが1週間。
話の脱線なんだが、新宿変電所を立て直す際にJRは送電の容量アップ、冗長化を進めたのね。それはインフラ企業として正しい事。
でも冗長性は普段は遊びになっちゃう。そして蕨からの送電は東電への電力料金が発生する。鶴見の発電は天然ガス代の支払いが発生する。信濃川はタダだ。連系系フルに活用できるだけのインフラも増強した。但し取水制限がある…。
という訳で「冗長化した設備の有効活用」が動機になってああいう不正をするようになっちゃったって面があるのよね。
新宿発電所の事故はこんだけ大変だったのだが、新宿はスター型結線の末端（少しハブの機能もあった）。
それに引き換え、蕨は大本のハブなのだ。今回の自体の深刻さが判って頂けただろうか？
望みは連系線フル活用できるように冗長構成がされていて信濃川でインチキしていた頃の取水をすれば被害を減縮出来そうってところ。
明日あたりに国に「蕨壊れちゃった…」と言って取水量大幅アップの許可取るのでは？それと川崎火力のタービン全開にしたら運転間隔半分までにはしないで済むかもしれない。
増田の家は東京北部なんだけど、昼過ぎに2度瞬停があって一瞬暗くなり、デスクトップパソコンは落ちなかったが電子制御の扇風機は動作不安定になった。
今考えるとあれが蕨での事故の瞬間と東電鳩ケ谷の遮断の瞬間だったのかなと。
蕨交流変電所の役目知らない人は「何時復旧するの」とイライラするが、知ってたら諦めた方が良いと判るね。
それでも会社に行かねばならない人は線路脇の送電装置類を眺めてその機能を調べて時間を潰したらどうだろう？電車撮ってる鉄オタは白い目で見られるけど、送電系が気になる銅オタは白眼視されないのでおススメです。
今年2月にあったテキサス大停電のことだと思うけど、あのときは歴史上例を見ない-19℃という大寒波の影響で、再エネ風力（タービンの凍結）・LNG火発（パイプラインの凍結）・石炭火発（石炭の凍結）・原発（冷却水の凍結）など、多くの発電設備が止まってしまった。
原因は、風力タービンが欧州や日本で使われているような凍結防止型になってなかったこと、その他の火発・原発が氷点下気温に対応してなかったこと。つまり、テキサスの発電送電網は、再エネと化石エネと原発のすべてが、そもそも世界的に「再エネをやらなきゃいかんぞ」となった理由である気候変動に対して、極めて脆弱な状態のままだった。なおテキサスでは発電電力の2/3が化石燃料＋原発由来で、なかでもLNGのシェアが圧倒的に高いため、結果的にはLNGが大停電の主犯だったことになる。このことは、停電発生当初は再エネを苛烈に批判していたグレッグ・アボット知事も後に認めている。
この凍結への準備不足に関して、米連邦政府は昔から凍結対応をせよと警告してたんだけど（1980年代から何度か寒波による電力供給問題が起きていた）、テキサスはエネルギー政策では極めて反連邦的で、アボット知事の州政のもと、そうした連邦レベルの指示・規制を受けないよう、グリッドを切り離して独自の運用をしていた。
本来、電力というのは送電網を使ってどこからでもどこまででも容易に送電できるのが燃料エネルギーに対する長所なわけで、ただ地域内で個別の再エネ設備やLNG火発が止まっただけなら、他地域から送電すればよい。実際、テキサス以外の米本土各州はすべて州間のグリッド接続をしていて、そのほとんどは「東部インターコネクション」と「西部インターコネクション」という2つの送電網に集約されている。ところがテキサスは全米で唯一、連邦政府の規制を避けるために、州間グリッド接続をせず州単位の系統（テキサスインターコネクション）を運用しており、これが命取りになってしまった。電力が不足してもほとんど他州から電力を流せない状態になっていたのだ。
うまく機能する電力取引市場の大前提は、あらゆる発電設備と需要家が相互にグリッド接続されているということだ。だから欧州では地域間どころかEU全体に及ぶレベルで国際連系が形成され、非常に強靱で効率的な電力網が構築されている。テキサスはこういう流れに背を向け続けた結果、地域内の発電設備の一部が停止しただけで大ダメージを受けた。
というわけで、テキサス大停電は、今では再エネの技術的問題などではなく完全な「人災」だった、という評価になっていて、アボット知事は激しい批判に遭い、テキサスインターコネクションを管理するERCOTは訴訟を起こされている。この停電の教訓は、
①これまで以上の気候変動を想定した、よりロバストな発電設備を導入すべき。
②安定した電力供給のためには、広域グリッド接続をしっかりやるべき。
ということ。
ご指摘ありがとうございました。ついLをつけてしまった。仰るとおり、米国で火発に使われているのは液化してないNG（天然ガス）です。上のLNGは全て天然ガスと読み替えてください。
（このエントリは
の続きです）
増田は一期一会が基本だが、「記事への反応」は特定の相手とのつながり、いわばパイプライン、ホットライン(?)を保ちうる唯一な手段だ。
やり取りが白熱しているうちは自分の日記欄の上の方に自分が相手にした書き込みが表示されるから「記事への反応」の変化に気づきやすい。
しかし永遠に続く熱量というものはなくだんだん双方とも書き込みの頻度が落ち込んでいく。すると相手に最後にした書き込みは他の書き込みに埋もれて2ページ以降に追いやられていくことになる。
こうなった時点でだいたいの場合その「記事への反応」は二度と確認されなくなる。
といっても細く長く続けるタイプの粘着もいてそういうのはしばらく相手から反応がなくなっても適当に他の増田に茶々を入れながら頭の片隅にその相手のことを覚えておくものだ。
2ページどころか３ページ目とかになっても完全にはつながりは途切れない。最初数分間隔でトラバし合ってたのが一日ごとになっていく場合もありえる。
こういう関係は最高何日(いや何ヶ月？)持つものだろうか。お前らの経験でいいから教えて欲しい。
個人的には同じ相手への一連のツリー内のトラバには回数制限を設けてほしい。たまにものすごい粘着がいてきりがない。レスバトラーだらけの知恵袋すら同じ質問者に対して最高百回あるいは七日間までしか返信できないようになってるのに…。
遊びには２種類の側面がある。「現実」と「非現実」である。 ～俺～
俺が求めていたゲームってのは現実から離れて自由に遊べる非現実空間だったんだ。
何も考えてない人向けなJ-POPで歌われる「リセットボタンで全てが終わるテレビゲーム」こそ俺のやりたいゲーム。
そこに帰ってくるのに１０年の歳月を要した。
いつからかチームプレイゲームで勝ち負けを全てとする割に自分は下手くそで、それを認めたくないばかりに味方のせいにしてばかりいる荒らしになっていた。
気晴らしに一人プレイゲームをやっているときでさえ、実績の達成率が気になってしまい動画攻略をなぞってクリアしては「この実績持ってないやつの発言とか無意味やぞ？」「動画見てクリアの何が悪いんだよ努力ってそういうものだろ？」と掲示板やチャットで連投する荒らし行為を続けていた。
違うんだ……俺が求めていたゲームはこんなんじゃない……５年前にはそう気づいていたが、今ここで逃げたら敗北を認めるような気がして必死に誤魔化しながら自分の中のゲーム像と戦っていた。
ようやく答えが出た。
俺はJ-POPの歌う「リセットボタンで全部が終わるヌルい世界」が好きなんだ。
「現実と地続きでもって生まれた動体視力、計算能力、情報収集力、コミュ力、それらを複合した総合的なゲーム力によって優劣が決まる世界」は、間違って渡ってしまった橋の先にある別の島だったんだ。
『横断歩道の信号待ちで、本当に渡りたい側が赤信号だった。そこと直角に交差する別の信号が青だから、折角出しさっきにそっちを渡った。でもそこでそっちを渡ったのは完全に間違いで、でもそれを認めたくないから目的地の近くまで反対の岸をあるき続けたら、引き返すタイミングがなくなってしまった』そういった経験が誰にでもあるだろう？
ヌルいより、ストイックが偉い。１人プレイより、複数プレイの方が高度。実績を持ってる奴が正しい。ランクが低いやつはノイズ。勉強してない奴は発言するな。本当に好きならやり込める。結果を出すのが愛の証明。そういったゲームコミュニティのなんちゃってマチズモに振り回されて、間違った場所でずっとゲームを遊んでいた。
かわいいキャラクターと一緒にスローライフを送るゲームを、やたらノンビリ遊んで周りから「Aさん。もしかして行き詰まってますか？ゲーム内時計を弄ると～～」みたいな余計なアドバイスを貰うようなペースで遊んでも良いんだ（この話はフィクションです）。
実績が意味を持つ世界を生きるかどうかは、プレイヤーが決めるものだ。
ランクってのは同じ強さのプレイヤー同士がマッチするためのもので、高い人が偉いってものじゃないんだ。
でも、そういうのはもういい。
俺はもう現実と非現実の間にあるパイプラインを徹底的に切り落とし始めたから。
１人でのんびり遊ぶから、急いでトレンドを追うこともしないし、感想を誰かと語り合うことだってやめる。
プレイした本数でマウントを取るために有名ゲームを片っ端からやるのだってもう辞めた。
自由だ。
やりたい時にやりたいゲームをやる。
俺だけの世界にこもるための触媒としてだけゲームがあり、その世界のことを他人と比べることもなくした。
癒やされる。
どうせゲームの世界なんて開発者の手垢まみれなんだから、別のプレイヤーなんて居なくても孤独になんてなりようがないんだよなあ。
いっそ寂しさを感じたかった。
なんか今度は、開発者の残した自己主張や価値観の声が煩く聞こえてくるよ。
どこまでも現実と地続きではあるんだなあ。
