  |
はてなキーワード: リージョンとは
国内盤は無規制です！つってハシャギながらクィアな関係を示唆するテキストはしっかり消してたらしいDead Spaceを思い出しますネ(ぼくは未プレイなんだけど)。EA日本支部はそういうスタンスなんだな～。
https://twitter.com/makichang23/status/1685508976031780864
↓
↓
ゲーム会社の方がこういうことを公開で言ってしまうことにかなり失望感あるな～やってること悪質なゲームコミュニティと変わらなくないですか？
https://twitter.com/mttk3029/status/1685570423294222336
↓
こちらのツイートですが、当該の人物とDMで話し合いを行い、ツイートを削除していただいたので、こちらの発言を撤回いたします。
なおツイート自体を消してしまうといらぬ誤解を生んだり文脈を見失ったりしてしまいかねないので、あえて残しておきます。
https://twitter.com/mttk3029/status/1685607561712771072
IGN Japanは渡邉卓也というライターがFF16を「体験版が一番おもしろかった」とDisったり、発売前に「樽も壊せないの？」と煽って吉田Pに発売前生放送で注意されたり、最近ではAC6のプレイ動画でシステムも理解できないド下手ライターに「カメラ操作がストレス」「ソウルライクではない」等
意味不明なネガキャンをやらかしててヘイトが溜まっているところにこれ。「インチチゲハニュースジャパン」という蔑称にふさわしいメディアだね。東京五輪開会式批判をゴリゴリの左翼＆割れ厨ライターワニウエイブに書かせたGamesparkといい勝負のクソメディアだわ。
そういえば渡邉卓也はリメイク版Dead Spaceについて「敵がアイテムを落とすと萎えるわ」というネガキャン記事挙げてたし、批評と勘違いしたオナニー記事で金貰える会社なのかね、IGNJ（産経系列）は。
AMD Software、これウィンドウモードでまともに録画できないのゴミじゃね
リージョンで一応できるけどターゲット選択挟むからワンボタンじゃできないし
設定項目こそ多いもののGeforce Experienceみたいに快適に出来ないなら周知しといてくれよ
ついでに全画面で起動するとradeon super resolutionへの書き込みアクセスがあることを確認してくださいとか毎回でてウザいしそれ消すためにトースト通知まるごとオフにしたり使わん機能オンにするのも違うじゃん
指標を表示ONすると録画中タイマーみたいなのを四隅に表示できて、これONじゃないと録画中であることを示すもんが何もないからONにしとくかと思ったらこのインジケーターまで映像に録画されちゃってるし
ついでにリージョンで開始するときのサイドバーも映り込むじゃん
インスタントリプレイ的なのもフルスクリーンorデスクトップ全録画じゃないと効かないしほんまこれ
こんなんOBSの方がよっぽどいいだろ
OBSはOBSでゲーム解像度変更に追従できなかったり予め起動しないといけなかったりで気軽な録画用には面倒だしファイル名にゲーム名入らんから分類面で不便だわ
もしやろくに設定ができないハードウェアエンコードも使えてないと思われるWindowsゲームバーが利便性では最有力候補になってしまうのか
AMDよ……やってんなあ
Geforce Experienceの右下◎が恋しいぜ
今年もスーパー耐久始まるので去年の振り返り
良く言えば独自色、悪く言えばいつ喋ってもDAZN臭くコメント欄までなんJ汚染を呼び込む笹川裕昭
その出自からキャリアのある老人に何も言えず、話の腰を追ったり割り込む事が致命的に弱いシャーリー半田
喋りだすと延々と昔話しかしない為、競技に急変があっても止まることができないので起用ポイントに難のある関谷正徳
関谷はこの際タイミングが悪かったにしても他二人はそれぞれ自分のチャネルなりリージョンがある人達なので引きこもっててほしいし、何を考えてSTOも呑んだのか理解しがたい
シャーリー半田はスーパー耐久公式のレギュラー陣とセットで運用しないとダメだというのは何も去年発覚したことでもなし、予見できた事故を起こした印象が強まるばかりだった。
一昨年はまだ比較的大人しい様相だったが昨年の言動はサーキットやレース関係者への敬意を欠いたものが目立った。
オーダを知らないで書かれたコードなんかよりもっとやばいのが並列処理な
爆弾みたいなもんだけど、世の中のシステムにかなり内包されてる
こんな感じで人類はまだ並列処理の最適解を見つけていない
そのくせに「並列化したら早くなるよね！」っていう人が多いので事故ることが多い
【追記】
愚痴聞いてくれてありがとな
子供できて自分のお金をポケモンに思い切り使えないんだよ。そしてこのまま失速しつつ攻略サイトや図鑑だけ見ている自分がいたらと想像してしまったんだ。そんな自分を中学時代の俺は軽蔑していただろう。せめて自分のできる限界まではしろ、と。
まあそんなこと気にしなくていいんだろうけどね。真面目に全クリしたきたわけでもないし。厳選や対戦もさほどしてないし。
だけどさ
新しい地方、新しいポケモン、新しい敵やストーリー。ようは数年に一度の出会いの儀式なんだよね。そんだけだが、そのためにずっとやってきたのは自分でも驚きだな。
やっぱ続けようかな。
---
本家の正統バージョンはソードシールドまでやったけど、ぶっちゃけ図鑑は完成していないしダウンロードコンテンツはやっていない。金と時間がなかったんだ。
更に言えばアルセウスはまるで手を付けていないので、初代伝説鳥のリージョン違いもほぼ知らない状態だ。というかサンムーン前後から知識が曖昧。
アニポケもGoもやってないので、ようはここ数年のポケモンの意識はゼロに等しい。もはやポケモンの名前すら言えるかもわからない。
そのうえで新作を買うべきかとても悩む。大会に出るとか図鑑コンプにはまるで興味はないのだが、新しいポケモンを見たときワクワクや新要素が欲しいのだ。
でもそれらが過去作に出ていたポケモンのリージョン違いや進化・進化前だと、過去作を中途半端に放置していたことを後悔しそうなんだ。
あのときプレイしていればこのポケモンに出会えたのに、なんでしなかった？とね
新しいポケモンに出会える機会を逃して、中途半端に攻略サイトで得た情報で満足する自分が嫌いだ。
別に俺の時代には攻略サイトは悪ではなかったし、ノベルゲーとかはぶっちゃけ全部選択肢をサイトに頼ることもある。
けれどポケモンはそれをしたくない。
かつて金銀の攻略情報をファミ通(古)で得た上でソフトを買ったときは非常に後悔したからだ。自分の歴史はポケモンとともにあった。近年はそうでもないが、新作はできるだけ継続している。
だからといって過去作をプレイする余裕があるかというと難しい。ああいうのは勢いとワクワクが全てなので義務感でやるのは辛い。
ここでポケモンの系譜を経てばそれでおしまいになりそうでもある。そうしたらもうポケモンを見ても何も感じないだろう。
でも子供が大きくなりポケモンに触れたとき、そのポケモンの名前くらいは言えておきたい。一緒にアニポケを楽しみたいし10年後の新作を一緒にプレイしたい。
ポケモンへの興味と知識を失うのは簡単だが、戻すのは苦労がいる。新作をプレイするのはモチベーション維持でもある。他のゲームはどうでもいいけど、ポケモンはそうじゃない。
ピカブイから最新のアルセウスまで書きます。主に第八世代を追記修正しました。
第三世代～第五世代：anond:20220812150701
第六世代～第七世代：anond:20220812184049
第七世代と第八世代の間に発売された「ポケットモンスター Let's Go! ピカチュウ・Let's Go! イーブイ」のことを
便宜上7.5世代と呼ぶ人もいる。ピカブイ限りのシステムもあるので参考程度に書く。
今作からイーブイの声が悠木碧のものになった。これは第八世代でも継続される。
ピカブイは一応初代のピカチュウバージョンをリメイクしたゲームという体裁だが
ポケモンGOとの連動を強く意識したゲームで、システムにもポケモンGOの影響がある。
ポケモンGOではポケモンを博士の研究所に送ったときにもらえるアメでポケモンを強化するが、
ピカブイでも同じようにアメをもらえ、ポケモンをレベルとは別に強化できる。
これは本編では導入されなかったが、第八世代では経験値アメという似て非なるアイテムが導入された。
ポケモンGOでのポケモンゲットはタッチパネルを使ってボールを投げるの方式だったが、
ピカブイではSwitchのJoy-Conを使って投げる動作を行うこともできる。
でも面倒なのでSwitchの携帯モードでボタンを押す方式のゲット方式にする人が多いと思う。
今まではポケモンセンターに行かなければパーティを編成できなかったが、
ピカブイではポケモンセンター外でもポケモンの入れ替えが可能になった。
メガシンカとZワザが廃止された代わりに導入された戦闘中1度だけ使える特殊システム。
ポケモンが数ターン巨大化して、その間はわざも「ダイマックスわざ」に変化する。
どのポケモンで、どのタイミングでダイマックスを切るかという駆け引きは結構好評だったと思う。
また、ポケモンによっては「キョダイマックス」という特別なすがたに変化して、
わざも通常のダイマックスわざとは違う「キョダイマックスわざ」を使うことができる。
今回はエメラルド・プラチナやウルトラサンムーンのようなマイナーチェンジは発売されなかったが、
その代わりに有償の追加ダウンロードコンテンツとして「鎧の孤島」と「冠の雪原」が遊べるようになった。
前回のウルトラサンムーンが「DLCみたいな内容なのにフルプライスなのはおかしい」と言われていたし、
料金も2000円ちょっとで以前と比べてかなり良心的になったと個人的には思う。
ガラル地方にはワイルドエリアというオープンワールド風フィールドがある。
ポケモンもシンボルエンカウントとなったがあくまでオープンワールド「風」なので
別にポケモンに襲われて死ぬ事は無い。後述のアルセウスでは死ぬ。
ワイルドエリアにあるポケモンの巣から光の柱が出ているときに、
倒せばそのポケモンを捕まえるチャンスが与えられ、またいろんなアイテムも手に入る。
これがまた大縄飛びを面倒臭くしたようなゲームで、正直面白くなかったんだよね…
DLC「冠の雪原」で歴代の伝説のポケモンと出会うチャンスもあるダイマックスアドベンチャーも追加された。
例えばルビサファで初登場した「マッスグマ」にはガラルのすがたがあるけれど、
そこからさらに「タチフサグマ」というポケモンに進化するようになった。
つまり従来のマッスグマには進化が与えられないわけだ…そこはちょっと悲しいね。
ちなみに伝説のポケモンのリージョンフォームが登場したのも第八世代で、
初代に登場したファイヤー・サンダー・フリーザーのリージョンフォームが登場した。
サンムーンまでに809種類ものポケモンが追加されてしまったので、いよいよ限界が来てしまった。
ポケモンは開発期間がビジネス上の都合で制約がある(ゼルダのように4年も5年も開発期間を裂けられない)ため
全てのポケモンを新しい作品に連れて行くことは今後できないという話だ。
例えばサンムーンで初登場した「ネッコアラ」は最新作の剣盾やアルセウスには連れて行けない。
ただ、リストラされてもポケモンHOMEのようなクラウドサービスには残せておけるため
今後リストラされたポケモンが復活するまでHOMEで寝かせることはできる。
とくせいパッチを使用するとポケモンのとくせいを隠れとくせいに変更できるようになった。
また、ミントで性格のステータス補正を別の性格のものに変更できるようになった。
これらによって厳選難易度が落ちた。
正直、とくせいパッチにしろミントにしろもっと早く実装して欲しかった要素だ。
俺はそういうの疲れちゃったからポケマスやってるよ。
わざレコードはマックスレイドバトルなどで手に入れることができる。
「Pokémon LEGENDS アルセウス」は今のところポケモン本編最新作だが、
従来のシリーズとは大きく違っているため便宜的に8.5世代とする。
次回作のスカーレット・バイオレットでも電子音が継続されるらしい。
なんと今回はポケモンと戦闘に入るまでが3Dアクションとなっている。
モンスターボールを自分で狙って捕まえられ、相手が気づかないうちに遠くから狙い獲ることもできる。
ただしポケモンもプレイヤーを襲うし、プレイヤーの体力が尽きると持っていたアイテムをフィールドに落としてしまう。
ヒスイで最初に出会うラベン博士も「ポケモンは怖い生き物です！」と言っている。
オヤブンと呼ばれるオーラをまとったポケモンは特に強く、プレイヤーにはかいこうせんを撃ってくるものもいる。
ポケモンを逃がしたり捕まえたりすると通称ガンバリアイテムと呼ばれるアイテムをもらえる。
今作のポケモンにはガンバレベルという個体値的なパラメータが設定されているのだけれど、
ガンバレベルはガンバリアイテムを与えていくと最終的にMAX(10)まで上昇する。
従来の個体値や努力値(ポケモンを倒すと取得できるいわゆる基礎ポイント)を統合させたような仕組みで、
今後はこれでもういいんじゃねえかという気持ちになってくる。
他にもいろいろあるけど、正直書き切れないわ。勘弁してくれ。
「日本人が」なんて増田には一言も書いてないけど誰にキレてるの？
リージョンを区切ってるのは大会運営側だし、「そういうくっだらねえ国境線で仕切られた世界から卒業するのがオンラインゲームの目標」って誰の目標？初めて聞いたけど。
多分fpsエアプだと思うけど、本気で全世界の人が同じ環境でプレイできると思ってる？fpsでどれだけpingが重要かわかってる？コロナ禍にも関わらずオフラインで大会が開催され、観客もオフラインを望んでる意味わかってる？
君みたいに暴言吐く人がいるせいでEsports全体のイメージが悪くなるから、本当にゲーム界隈のことを考えてるならネットで発言しないで欲しいな。
まあ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%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
