  |
はてなキーワード: クローとは
まあVMWorldとかで10年以上人生の春を謳歌してきたからもう十分やろ
お疲れさん
～VMwareが提案する、DRにも対応するマルチクラウドソリューション～
昨今のCOVID-19流行への対応やDXを推進する中で、クラウドサービスの利用はビジネススピードの加速や柔軟なシステム運用に効果的であり、従来のオンプレミス環境と併用するハイブリッド環境や、複数のクラウドを利用するマルチクラウド環境が増えている。一方で、これらの環境を維持していくには課題も多く、セキュリティリスクも増大してしまう。ここでは、こうした課題を解決するVMwareのソリューションを紹介する。
COVID-19流行への対応やDX（デジタルトランスフォーメーション）のためのビジネス変革が進む中で、ビジネススピードの向上やニーズに対する迅速で柔軟な対応がこれまでになく求められている。これらを実現するために、アプリケーションの変革やクラウドへの移行が加速している。
多くの企業が、「ビジネスのスピードに対応できるモダンアプリケーション」や、「あらゆるクラウド、データセンター、エッジでビルドおよび実行が可能であること」、「エンタープライズクラスのレジリエンス、セキュリティ、運用の実現とビジネス変革」がDXを実現するために必要であると考え、これらを実現するためにマルチクラウド環境の活用が前提になってきている。
具体的には、Amazon Web Services(AWS)、Microsoft Azure(Azure)、Google Cloud Platform(GCP)といった複数のパブリッククラウドサービスを併用し、適材適所で使い分けているのが現状であろう。しかし、マルチクラウド環境では解決が必要な課題が存在する。その課題とは、「ワークロードのシームレスな移行・連携」、「クラウドごとのスキル習得」、「運用管理の簡素化」、「セキュリティリスクの低減」、「最適なコスト管理」の5つである。この5つがクラウド利用の理想と現実のギャップとなっており、これらを意識して進めていく必要がある。
特にマルチクラウド環境を適材適所で使う場合、クラウドごとに利用する技術が異なるため、設定項目や内容に違いがあり、その設定ミスによるインシデントも発生している。重大な影響を及ぼす場合もあるため、それぞれのクラウドを扱う際のスキルが重要になる。
こうしたマルチクラウド環境における課題を解決するには、一貫性のあるクラウドインフラストラクチャ、および運用管理サービスが重要なポイントとなる。例えばVMwareは、複数のパブリッククラウドだけでなくオンプレミスを含むハイブリッドクラウド環境においても、仮想的なレイヤーを構築することで管理や運用を一元化している。
VMware Cloud on AWSは、VMwareとAWSが共同で開発したもので、AWSのベアメタルサーバー上にvSphere、NSX、vSAN、vCenterを導入し、ホスト専有型のクラウドサービスとして提供するものだ。
その特長は3つある。1点目は「VMware製品をベースとしたクラウド」であること。VMware製品で仮想化されているため、AWSの世界にいながらオンプレミス環境で利用していたスキルセットや運用管理ツールを利用でき、新たなスキルを習得する必要がない。
2点目は「シームレスにクラウドに移行できる」こと。ワークロードをオンプレミス環境から無停止で移行することができる。アプリケーションを更改する必要もないため、クラウドに移行する時間やコスト、リスクを大幅に削減することが可能だ。
3点目は「VMwareが管理を行う」こと。ハードウェアやソフトウェアのトラブル対応や運用管理、メンテナンス対応など、すべてサービスの中でVMwareが実施する。3カ月に一回の頻度で新しいリリースを提供しており、ユーザーの要件を反映しながら新たな機能を追加している。
最近のアップデートの大きなものとして、日本で第2のリージョンとなる大阪リージョンを設置し、サービス提供を開始したことが挙げられる。例えば西日本地区でデータセンターを持つユーザーは、より低遅延でサービスを利用できるようになった。昨今は感染症の流行や地震の発生などによってBCPを見直すユーザーが増え、VMware Cloud on AWSをリカバリサイトとして利用するケースも増えている。その意味でも、大阪リージョンは活用度が高いといえる。
VMware Cloud on AWSが選ばれる理由は、大きく3つ挙げられる。1点目が既存のノウハウや運用管理手法をそのまま踏襲できるという点。VMware製品をベースとしたクラウドサービスであるため、オンプレミス環境における管理者のスキルや運用ノウハウなど、既存の資産をそのままクラウド上でも活用でき、新たなスキルの習得や、運用管理手法の大きな変更の必要もない。クラウドとオンプレミス環境をvCenterから一元管理できる。
2点目が、規模に依存しないシンプルなクラウド移行を実現できる点。ワークロードをそのままクラウドへ簡単に移行することが可能だ。VMware Cloud on AWSには標準でVMware HCXが含まれ、これはオンプレミスのデータセンターとクラウド間のネットワークをL2延伸する。ネットワークがつながった環境で仮想化環境、VMをそのままマイグレーションできる。アプリケーションやIPアドレスを変更することなく、無停止でワークロードを移行することができる。
3点目が、モダナイゼーションを推進して、ユーザーのDXの加速を支援できる点。まず、クラウドならではのインフラストラクチャとして、1顧客あたり最小2ホストから最大640ホストまで拡張できるが、俊敏性を兼ね備えて提供される。例えば、ホストの展開に1時間半程度、ホスト数を追加するのに15分程度と、オンプレミス環境ではありえないスピード感で環境を構築、提供される。
また、リソースを最適化する機能も提供される。ユーザーのリソースの使用状況に応じて、利用するホストの台数を自動的に増減させて最適化する。さらに、名前の通りにAWSが提供する各種サービスとの親和性が非常に高いことも特長。VMware Cloud ENIと呼ばれる専用のインタフェースを経由して接続することで、低遅延で高速な環境を利用して各種のAWSのサービスとシームレスに連携することができる。この面も同サービスの大きな強みとなっている。
最近では、VMwareが提供するKubernetesディストリビューションであるVMware TanzuをVMware Cloud on AWS上で稼働させることが可能になった。これにより、短時間でコンテナ、Kubernetes環境が導入できるようになる一方で、ハードウェア、ソフトウェアの管理はすべてVMwareが行うため、管理者はKubernetes環境に集中できる。
VMware Cloud on AWSのユースケースには、主に「オンプレミス環境のクラウド移行」、「データセンターの拡張」、「災害対策サイト」、「次世代アプリケーションのプラットフォーム」の4つが多い。特に最近は、災害対策としての利用が増えているという。VMware Cloud on AWSをリカバリサイトとして活用する際に強力なサービスとなるのがVMware Cloud Disaster Recoveryだ。
VMware Cloud Disaster Recoveryを利用すると、平常時には本番サイトのデータをクラウド上のストレージ領域にレプリケーションしておき、万一DRイベントが発生した際に初めてVMware Cloud on AWS上にホストを展開し、保護していた仮想化環境をフェイルオーバーする。リカバリサイトとしてあらかじめ物理的なサイトを構築しておく必要がないため、大規模な初期投資が不要となる。
VMware Cloud Disaster Recoveryの特長
このタイプはオンデマンド展開型と呼ばれ、DRイベント時にホストを展開したタイミングでリカバリサイトに対する課金が開始される。復旧後に仮想化環境を本番サイトに戻すことで、ワークロードもフェイルバックでき、不要となったリカバリサイトのリソースも削除され課金も停止される。なお、オンデマンド展開型のほかに、事前にホストを展開しておく事前展開型も用意されており、RTOを重視する場合には事前展開型が推奨される
また同サービスは、最近話題になっているランサムウェアへの対策にも有効だ。クラウドストレージ上に本番環境のデータをバックアップする際には、リカバリポイントを長期的に保持することが可能である。このため、ランサムウェア攻撃に遭ってしまった場合、その直前の時点からリストアすることが可能となる。
マルチクラウド環境を可視化するVMware vRealize Cloud
マルチクラウド環境では、各クラウドが複雑化し、サイロ化してしまう可能性がある。クラウドごとに管理ツールや必要とされるスキル、ノウハウも異なるため、利用するクラウドが増えるほど複雑化、サイロ化の問題が大きくなり、その結果セキュリティリスクやコストが増加してしまう。そこで有効な解決策となるのが、クラウド環境をまたがって一貫性のある運用・管理を実現できるVMware vRealize Cloudである。
まず、VMware vRealize Operations Cloudは、VMware Cloud on AWSのリソースだけでなく、他のパブリッククラウド上のリソースも一元管理できる。複数クラウドの環境にまたがってデータを収集、分析評価を行うことで、例えば常にパワーオフ状態の仮想化環境や、実体がない状態のディスクなどを検知された場合に最適化していくことが可能。これにより、最終的にコストの最適化も図ることができる。
コストや運用を最適化できるVMware vRealize Cloud
また、VMware vRealize Log Insight Cloudによって、複数のクラウドを横断してログを管理できる。例えば、監視対象のイベント通知をあらかじめ定義しておくことで、不正な行動を検知した際には管理者に通知し、適切な調査と対応を行うことができる。セキュリティやコンプライアンスの強化にも有効だ。
さらに、クラウド間のネットワークの可視化は、VMware vRealize Network Insight Cloudで実現できる。End to Endを含むネットワーク全体を可視化できるため、ネットワークに関するトラブルシューティングや、不審な通信を洗い出すこともできる。また、アプリケーションの通信も把握できるため、アプリケーションの移行計画にも活用できる。
今後、DXの推進を加速していく上で、必ずしもひとつの環境、ひとつのクラウドを利用するのではなく、マルチクラウド環境の利用が当たり前になっていくと考えられる。そこで直面する前述の5つの課題に対し、VMware Cloud on AWSそしてVMware vRealize Cloudの活用は課題を解決するだけでなく将来への有効な投資となる。企業規模や業種に関係なく検討すべきソリューションといえるだろう。
--
この本は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%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
公式くんよお～～～？まさか適正な運営どころか計算もできないほど脳ミソおからなんか？？？
ディアソムニアのメンバーだけスタンプ少ないってなんだよ！！！
整理して考えよう
スカラビア→２人
ポムフィオーレ→３人
イグニハイド→２人
オンボロ→１人(グリムのみ)
で、合計21名なわけじゃん
そこに先生ら5人入れても26人
スタンプ２個なんて寮長とグリムだけでよくない？？？(全員２個じゃないと不平等なのは全方位に謝罪します。別に寮長ひいきとかではなくキービジュとか広告的にない頭を絞り出しました。絶対他に正解がありそうだけどすまん)
LINEスタンプはひとつの販売枠に最大40個しか登録できない、だとしたら
21(全員分)プラス8(各寮長とグリムの追加分)で28個なわけじゃん
先生のスタンプ一個ずつ追加しても33個ですが？？全然余裕で全員入りますけど？？
というか全員２個ずつスタンプ作りたいんならスタンプ何パターンかに分けりゃいいじゃん(気づき)
ハーツサバナ、オクタスカラポム、イグニディアソで3パターンなら全然余裕で1キャラ２～3個実装できますけど？？？
複数パターン出せばコンプ勢は3つとも買うから儲け増えるじゃん
まじでバカ？？
とにかく上から順番に二個ずつ埋めてこ！足りんかったわごめんな～教師陣らは枠すらないわ～ってこと？？？キャラゲーの商品ぞ？？
よく刀剣乱舞引き合いに出すけどさ、刀剣乱舞でもここまでひどくないぞ(リリース当時から通して全く無かったとは言わないし絶対許さねえけど)
ここまでなめ腐った商品初めて見たわ
ツムツムでも思ったけど、本当に雑な扱いするよね
まじで訳がわからないよ
一つのテーマ、受賞者最大3人、に授与するというルールだったと記憶してるけど
ワンテーマから3人の時と、隣接領域から受賞者詰め込んだのかな、みたいな時があるよね。
なかでも今年は飛びぬけて関連性なくない？なくなくない？
1997年 レーザー冷却法［スティーブン・チュー、クロード・コーエン＝タヌージ、ウィリアム・ダニエル・フィリップス］
2008年 自発的対称性の破れの発見［南部陽一郎］ CP対称性の破れを説明するクォーク理論［小林誠、益川敏英］
2009年 光ファイバー通信［チャールズ・カオ（高錕）］ CCDセンサーの発明［ウィラード・ボイル、ジョージ・E・スミス］ ←ちょっとこじつけっぽい
2018年 光ピンセットの開発［アーサー・アシュキン］ 超高出力・超短パルスレーザーの生成方法［ジェラール・ムル、ドナ・ストリックランド］
2020年 ブラックホールと一般相対論［ロジャー・ペンローズ］ 銀河系中心いて座A*の発見［ラインハルト・ゲンツェル、アンドレア・ゲズ］
2021年 気候モデル・温暖化［真鍋淑郎、クラウス・ハッセルマン］ スピングラス［ジョルジョ・パリージ］ ←地球規模に適用できる複雑系の研究？
日本では真鍋さんの人物エピソードだけ報道され解説が少ないであろうスピングラスは、統計物理学が専門だったヨビノリの解説を見るといいと思う。
俺は見たけどよくわからんかったわ。ジョルジョの研究分野が多彩で広い分野に影響を与えたすごい学者なのはWikipediaの受賞歴からも感じられた。
同一テーマの受賞がほとんどだけど、その中から1997年のレーザー冷却法をピックアップしたのは、レーザー冷却法にアーサー・アシュキンの考案した技術が使われていて
受賞したチューもアシュキンが先駆者だと言ってたことが2018年のアシュキン96歳当時最高齢ノーベル賞受賞につながったのかなあ、とか思って入れました。
ペンローズも「2020年に、ブラックホールと相対論で受賞するのが、ちょうどいいのか？」という点に、光電効果のアインシュタインみを感じて入れた。
貨幣の前身は、言語とともに、初期の現代人が他の動物が解決できない協力の問題を解決することを可能にした。これらの原型は、非フィアット通貨と非常に特殊な特徴を共有しており、単なる象徴や装飾品ではなかった。
17世紀のイギリスのアメリカ植民地では、当初から硬貨の不足という問題があった。イギリスの考えは、大量のタバコを栽培し、世界的な海軍や商船の船のために木材を切り出し、その見返りとしてアメリカ人の労働力として必要な物資を送るというものであった。つまり、初期の入植者は、会社のために働き、会社の店で買い物をすることになっていたのである。投資家と王室は、農民の要求に応じてコインで支払い、農民自身に物資を買わせ、さらに天罰として利益の一部を確保するよりも、この方法を好んだ。
植民地の人々の解決策は目の前にあったが、彼らがそれを認識するまでには数年を要した。原住民はお金を持っていたが、それはヨーロッパ人が慣れ親しんできたお金とは全く違っていた。アメリカン・インディアンは何千年も前からお金を使っていたし、新しくやってきたヨーロッパ人にとっても便利なお金であった。しかし、ニューイングランドの人々は、銀も金も使わず、自分たちの生活に最も適したお金を使っていた。その代わりに、彼らは獲物の耐久性のある骨組みという、その環境に最も適した貨幣を使っていた。具体的には、ワンパムと呼ばれる貝（ホンビノスガイ）とその近縁種の貝殻をペンダントにしていた。
貝は海でしか採れないが、ワンパムは内陸部でも取引されていた。アメリカ大陸の各部族には、さまざまな種類の貝殻貨幣が存在していた。イリコイ族は、貝の生息地に近づかずに、最も大きなワンパムの財宝を集めることができた。ワンパムを専門に製造していたのは、ナラガンセッツ族などほんの一握りの部族で、他の何百もの部族（その多くは狩猟採集民）がワンパムを使用していた。ワンパムのペンダントは、長さとビーズの数が比例しており、様々な長さのものがあった。ワンパムペンダントの長さは様々で、ビーズの数は長さに比例しており、ペンダントを切ったり繋げたりして、支払った金額と同じ長さのペンダントを作ることができた。
入植者たちは、本当のお金とは何かという問題を克服すると、ワンパムの取引に熱中した。貝（clam）は、アメリカでは「お金」の別名として使われている。ニューアムステルダム（現在のニューヨーク）のオランダ人知事は、イギリス系アメリカ人の銀行からワンパムで多額の融資を受けた。しばらくすると、イギリス当局もこれに同調せざるを得なくなった。1637年から1661年にかけて、ニューイングランドではワンパムが法定通貨となった。植民地の人々は流動的な交換手段を手に入れ、植民地の貿易は盛んになった。
ワンパムの終わりの始まりは、イギリスがアメリカ大陸に多くのコインを出荷するようになり、ヨーロッパ人が大量生産の技術を応用するようになってからである。1661年になると、イギリス政府はワンパムの製造を中止し、本物の金や銀、そして王室の監査を受けてブランド化されたコインで支払うことにした。この年、ニューイングランドではワンパムは法定通貨ではなくなった。1710年にはノースカロライナ州で一時的に法定通貨となった。ワンパムは、20世紀に入っても交換手段として使われ続けていたが、その価値は西洋の収穫・製造技術によって100倍にも膨れ上がり、貨幣が発明された後に西洋で金や銀の宝飾品が行き渡ったように、よくできたお金から装飾品へと徐々に変化していった。アメリカの貝貨の言葉は古風な遺物となった。百貝は百ドルになった。「Shelling out」とは、コインや紙幣で支払うことを意味し、やがて小切手やクレジットで支払うようになった。我々は、自分たちの種の起源に触れてしまったことを知らなかった。
ネイティブ・アメリカンのお金は、貝殻以外にも様々な形があった。毛皮、歯、そして後述する特性を持つ他の様々な物体も、交換手段としてよく使われた。12,000年前、現在のワシントン州で、クロービス族は、驚くほど長い角岩の刃を開発した。しかし、すぐに折れてしまう。これでは切ることもできない。火打ち石は「楽しむため」に作られていたのか、それとも切ることとは関係のない別の目的のために作られていたのか。後述するように、この一見軽薄に見えることが、実は彼らの生存にとって非常に重要であった可能性が高い。
しかし、ネイティブ・アメリカンは、芸術的ではあるが役に立たない刃物を最初に作ったわけではないし、シェル・マネーを発明したわけでもない。ヨーロッパ人も、昔は貝や歯をお金にしていたし、牛や金、銀、武器なども使っていた。アジア人は、それらすべてを使い、政府が発行した偽物の斧も使っていたが、この制度も輸入していた。考古学者が旧石器時代初期の貝のペンダントを発見しており、それがネイティブ・アメリカンのお金の代わりになっていた可能性があるからだ。
1990年代後半、考古学者のスタンリー・アンブローズは、ケニアのリフトバレーにあるロックシェルターで、ダチョウの卵の殻やブランク、貝殻の破片でできたビーズのキャッシュを発見した。これらのビーズは、アルゴン-アルゴン（40Ar/39Ar）比を用いて、少なくとも4万年前のものとされている。スペインでは、この時期に穴の開いた動物の歯が発見されている。また、レバノンの旧石器時代初期の遺跡からは、穴の開いた貝殻が出土している。最近では、南アフリカのブロンボス洞窟で、さらにさかのぼって7万5千年前に作られたビーズ状の貝殻が発見されている。
現代の亜種はヨーロッパに移住しており、紀元前4万年頃から貝殻と歯のネックレスが登場している。また、オーストラリアでは紀元前3万年頃から貝と歯のペンダントが出土している。いずれも高度な技術を要するものであり、もっと昔から行われていたと思われる。採集や装飾の起源は、解剖学的に現存する亜種の原産地であるアフリカである可能性が高い。人類が常に飢餓と隣り合わせの生活をしていた時代に、貝殻の製造には膨大な技術と時間が必要だったのであるから、収集してネックレスを作ることには重要な選択的利益があったはずである。
実質的な貿易を行っていない文化や、現代的な貨幣を使用している文化であっても、事実上すべての人類の文化は、ジュエリーを作り、楽しみ、実用性よりも芸術性や家宝としての価値を重視している。我々人間は、貝殻のネックレスやその他の種類のジュエリーを、純粋に楽しむために集めている。進化心理学者にとって、人間が「純粋に楽しむため」に何かをするという説明は、説明ではなく、問題提起なのである。なぜ多くの人が宝石を集めたり身につけたりすることを楽しんでいるのか？進化心理学者にとってこの問題は「何がこの楽しみを進化させたのか？」ということである。
進化心理学は、ジョン・メイナード・スミスの重要な数学的発見から始まる。スミスは、発達した集団遺伝学の分野から、共進化する遺伝子の集団のモデルを用いて、単純な戦略的問題（ゲーム理論の「ゲーム」）で使用される善悪の戦略をコード化できる遺伝子を提唱した。スミスは、これらの遺伝子が次世代への伝播を競っている場合、競争相手が提示する戦略問題に対してナッシュ均衡となる戦略を進化させることを証明した。このゲームには、協力の典型的な問題である「囚人のジレンマ」や、攻撃とその緩和の典型的な問題である「鷹と鳩」などがある。
スミスの理論で重要なのは、これらの戦略的ゲームは、近距離の表現型間で行われているが、実際には、究極のレベルである遺伝子間のゲーム、つまり伝播されるべき競争のレベルで行われているということである。遺伝子（必ずしも個体ではない）は、あたかも拘束された合理性（生物学的原材料と過去の進化の歴史を考慮して、表現型が表現できる範囲内で、可能な限り最適な戦略をコード化する）と「利己的」（リチャード・ドーキンスの比喩を使用）であるかのように行動に影響を与える。遺伝子が行動に与える影響は、遺伝子が表現型を通じて競合することで生じる社会的問題への適応である。スミスはこれらの進化したナッシュ均衡を進化的安定戦略と呼んだ。
性淘汰や血縁淘汰など、それまでの個人淘汰説の上に構築されていた「エピサークル」は、このより一般的なモデルの中に消え去り、コペルニクス的な方法で、個人ではなく遺伝子を理論の中心に据えることになる。このようにドーキンスは、スミスの理論を説明するために、「利己的な遺伝子」という比喩的でよく誤解される言葉を使っている。
旧石器時代の人間のように協力し合う種は他にほとんどない。雛の世話、アリ、シロアリ、ハチのコロニーなど、動物が協力するのは親族だからであり、親族にある自分の「利己的遺伝子」のコピーを助けることができるからである。非常に制約の多いケースでは、進化心理学者が「相互利他主義」と呼ぶ、親族以外の者同士の継続的な協力関係も存在する。ドーキンスの説明によると、好意の交換が同時に行われない限り（場合によってはその場合でも）、どちらかが不正を行うことができる。そして、普通はそうする。これは理論家が「囚人のジレンマ」と呼んでいるゲームの典型的な結果である。詐欺師と吸血者の集団では、常に詐欺師が勝つ。しかし、「Tit-for-Tat」と呼ばれる戦略を用いて、相互作用を繰り返すことで協力するようになる動物もいる。この報復の脅威が継続的な協力の動機となる。
しかし、動物の世界で実際にそのような協力が行われる状況は、非常に制約が多い。主な制約は、少なくとも一方の参加者が多かれ少なかれ相手の近くにいなければならない関係に限定されていることである。最も一般的なケースは、寄生虫とその体を共有する宿主が共生体に進化した場合である。寄生虫と宿主の利害が一致し、どちらか一方が単独で活動するよりも、両者が一緒に活動する方が適している場合（つまり、寄生虫が宿主にも何らかの利益をもたらしている場合）、Tit-for-Tatゲームを成功させることができれば、両者の利害、特に世代間の遺伝子の出口メカニズムが一致した状態である共生体に進化する。そして、1つの生物となるのである。しかし、ここでは協力だけではなく、搾取も行われている。それらは同時に起こる。この状況は、以下で分析する人間が開発する制度、つまり貢ぎ物に類似している。
寄生虫と宿主が同じ体を共有して共生体に進化するのではない、非常に特殊な例がある。寄生虫と宿主が同じ体を共有し、共生生物に進化するのではなく、同族ではない動物と高度に制限された縄張りを持つ、非常に特殊な例がある。ドーキンスは、クリーナーフィッシュを例に挙げている。この魚は、宿主の口の中を泳いで出入りし、そこにいるバクテリアを食べて宿主の魚に利益をもたらす。宿主である魚は、クリーナーが仕事を終えるのを待ってから食べるというズルをすることもできる。しかし、そうはしない。両者とも移動可能なので、潜在的には自由に関係を断つことができる。しかし、クリーナーフィッシュは個々の縄張り意識を非常に強く進化させており、偽造しにくいブランドロゴのように、偽造しにくい縞模様や踊りを持っている。宿主魚はどこに行けば掃除してもらえるかを知っているし、もし不正をしたら、新しい不信感を持った掃除魚ともう一度やり直さなければならないことも知っているのだ。この関係の入口コスト、つまり出口コストが高いので、不正をしなくてもうまくいくのである。それに、クリーナーフィッシュは小さいので、それを食べることで得られる利益は、少数の、あるいは1匹のクリーニングで得られる利益に比べて大きくはない。
最も適切な例として、吸血コウモリがある。その名の通り、獲物である哺乳類の血を吸う。面白いのは、良い夜には余剰分を持ち帰るが、悪い夜には何も持ち帰らないことだ。彼らの暗躍は非常に予測不可能である。その結果、幸運な（あるいは熟練した）コウモリは、洞穴の中で幸運でない（あるいは熟練していない）コウモリと血を分かち合うことが多い。彼らは血を吐き出し、感謝している受取人がそれを食べる。
このようなレシピエントの大部分は親族である。屈強な生物学者G.S.ウィルキンソンが目撃した110件の血反吐のうち、77件は母親が子供に食べさせるケースであり、その他のケースもほとんどが遺伝的な親族である。しかし、親族間の利他主義では説明できないケースも少なからずあった。これらが相互利他主義のケースであることを示すために、ウィルキンソンは2つの異なるグループのコウモリの個体群を組み合わせた。コウモリはごく稀な例外を除いて、元のグループの旧友にしか餌を与えなかった。このような協力関係を築くには、パートナー同士が頻繁に交流し、お互いを認識し、お互いの行動を把握するような長期的な関係を築く必要がある。コウモリ穴は、そのような絆を形成できる長期的な関係にコウモリを拘束するのに役立つ。
人間の中にも、非常にリスクの高い不連続な獲物を選び、その結果得られた余剰分を親族以外と共有していた者がいたことがわかるだろう。実際、人間は吸血コウモリよりもはるかに大きな範囲でこれを達成している。その方法が本論の主題である。ドーキンスは、「お金は、遅延した相互利他主義の正式なトークンである」と示唆しているが、この魅力的なアイデアをそれ以上追求することはない。我々はそうする。
人間の小集団の中では、世間の評判が一人の個人による報復よりも勝って、遅延型互恵主義の協力を動機付けることができる。しかし、評判を信じることには2つの大きな誤りがある。どの人が何をしたかについての誤りと、その行為によって生じた価値や損害を評価する際の誤りである。
顔や好意を記憶する必要があるというのは、認知上の大きなハードルであるが、ほとんどの人間は比較的容易に克服できると考えている。顔を認識するのは簡単であるが、好意を受けたことを思い出すのは難しい。また、好意を受けた人にとって、その好意がどのような価値を持つものであったかを思い出すことは、さらに困難である。紛争や誤解を避けることは、不可能なほど、あるいは法外に難しいことである。
パート2: https://anond.hatelabo.jp/20210906120933
パート3: https://anond.hatelabo.jp/20210906125926
パート4: https://anond.hatelabo.jp/20210906130017
パート5: https://anond.hatelabo.jp/20210906130125
・１０GB/３日を超えると1.0mbpsになる
・そもそも制限超えて無くてもピーカンの平日で20mbpsぐらいが限界
・有線の１０倍ぐらいの頻度で切れる
・別に安くない
・引っ越し手続きはウルトラ簡単かつスピード感がありネット受付で全部簡潔なので乗り換え作業だけは死ぬほど楽
・ネットでエロ動画を見続けることができなくなり健全な人生に近づく
・ネット対戦ゲームがまともにプレイできなくなり健全な人生に近づく
・突然ネットが使えなくなることがあるためネット依存症が改善する
・ネットのない生活に体が強制的に適応させられるのでネット依存症が改善する
・ビックリするほど簡単に申し込みが出来たがビックリするほど遅かった
・今まで使っていたマンション無料回線よりマシだったので喜んで検索したらゴミ回線と煽られており如何に自分の人生がゴミだったか自覚した
・フレッツでゴミのようなサポートを受けても有線回線が使えるありがたみを考えれば我慢できるようになった
・スマホ世代が語るインターネットの狭さに驚いていたが回線のナローさを知ることで納得ができた
・自分はゲームが上手いのではなく回線が強かっただけなのだとキルレの差で思い知った
ふらっと見たロボとーちゃんが期待より面白かったからまだたくさんあるしなんか見たい。
見たことある作品とか書いとくので暇ならおすすめ映画あげてくれい。
大人向けのわかりやすいパロディとコピー人格にありがちな葛藤がほぼなくとーちゃんに対しても終始自分がとーちゃんだと張り合ってたロボとーちゃん、しんちゃんとみさえの対比とかがよかった。
ホラーとコメディのバランス、同居感がすごい好き。世代で録画してたから一番見てて好きな映画。
ラストバトルのぼんやりとした記憶しかないけどオカマが好きだった気がする。
パラダイスキングと猿のキャラクター、格闘シーンがとてもよかった。
あと小桜エツ子が好きなのでミミ子くんが出ると加点です。
大人がいなくなったときの子供だけの無政府状態感とひろしの無声演出？が好き。
タイムスリップと戦国時代は好きだけどしんちゃんで見たい話じゃなかったな。
ストーリーにヤキニクロード関係ないなこれ…ってずっと気になって終始ノれなかった。
並べると思い出補正っぽいけどリアタイはたしかヘンダーとオトナ帝国ぐらいか。
雲黒斎とブタのヒヅメはよく話題にあがるから見ようと思いつつずるずる見ないままに…
カスカベボーイズは当時かすかべ防衛隊がメインっぽいから避けてて、あとのタイトルはキービジュアルもわからない状態だな。
いろいろなうまい方の意見やYoutubeに上がっている霧の森の住人たちのアドバイスはありますが、本当に初心者が必要なアドバイスを3ヶ月目の初心者が教えます。
ナンシーとかケイトとかドワイトとかも良いという意見もありますが、つまらなくてもまずはクローデットを育てるべき。セルフケアが無いと持ち物は医療キットを持っていくしかなくなる。セルフケア、共感は初動にマストなパーク。レベル15まで育ててパーク枠4つを開放することをまずは目指す。
共感、セルフケア、血族、猫。慣れてきたら共感か血族の代わりにデジャブをつけても良い。
共感が良いのは、最初に傷がついた人がわかること。つまりその時点でキラーはそこにいるということがわかる。絆だとみんなの動きが見えるため、初撃をもらって人を追いにくい。
初心者は怖くて走れないので無意味。最初はいらない。したがって全力疾走とかデッドハードとかは後回しで良い。
上手い人からは怒られそうだが、最初に見つかってすぐに死んでしまうことが続くとやる気が失せる。最初はしゃがみ歩きで遮蔽物の裏に隠れながら、キラーが誰かがわかるまではコソコソしておいたほうが良い。
その例外として、近くにいるサバイバーが発電機の修理を始める場合。その場合は一緒に修理しよう。見つかっても一発もらう確率は半分に減る。猫が2秒光ったら仲間を見捨てて走って逃げよう。
キラーのパークを無効化するチャンスなのでリスクを負ってでも破壊すべき。ただし近くに心音が聞こえる場合は隠れる。光っているトーテムは壊すと大きな爆発音とともに通知が行くので、すぐにその場を離れる。心音がしないようであれば歩いて身を隠すのが良い。まれに光っているトーテムが罠で、それを壊すと1分間1撃でダウンする状態（無防備）になってしまうものもある。キラーがそのパークをつけている可能性は低いので、当たったら運が悪かったと思い積極的に壊そう。
ダウンしたらその位置が人形で表示される（キラーのパークによって例外はある）。心音範囲外でそれが持ち上がったり、その人のアイコンが微妙に点滅しているならすぐに近くのロッカーに隠れよう。キラーの大半が装備しているバベチリというパークは、サバイバーを吊ったときから5秒間マップ全体のサバイバーの位置がオーラで見えるようになる。ただしロッカーにいるとわからない。心音範囲であるほどに近くなら見えないためそのまま隠れていれば良い。
非常に遠くであり、現在発電機の修理中であればそれを継続する。近くだったり、他のサバイバーが切られたりする（アイコンでわかる）なら助けに走る。
発電機は全部で7台ありそのうち5台を修理するわけなので、最後の3台が近い位置にあるとそこでキラーは待っているだけで勝ちになる。そのためバランス良く修理するのが望ましい。最初の1台は目の前ので良い。1台、2台くらいが直ったなら、その位置からみてマップの反対側かマップの真ん中のを修理しないと最後の3つが固まってしまう。誰かマップの端っこで追われているのが共感でわかったなら、真ん中付近を優先して修理しよう。デジャブをつけていると、固まっている3つの遠くの発電機の位置がわかるので、発電機を散らすために便利。
サバイバーでやりたいという方が多いと思うが、キラーをやってみないと足跡がどんなふうに見えているのかとかわからない。サバイバー5回やったらキラーを1回はやるべき。最初のおすすめはレイス。透明状態で高速で動ける、特技が透明化だけというシンプルさがとっつきやすい上にそこそこ強い。
