「リージョン」を含む日記 RSS

はてなキーワード: リージョンとは

2022-08-12

一応ポケモンを(略)ピカブイ・第八世代アルセウス

カブから最新のアルセウスまで書きます。主に第八世代追記修正しました。

三世代~第五世代anond:20220812150701

第六世代~第七世代anond:20220812184049

カブイ・第八世代アルセウス:ここ

おまけ:anond:20220812194606

7.5世代(ピカブイ):Switch

舞台カントー地方(赤・緑と同じ)

第七世代と第八世代の間に発売された「ポケットモンスター Let's Go! ピカチュウ・Let's Go! イーブイ」のことを

便宜上7.5世代と呼ぶ人もいる。ピカブイ限りのシステムもあるので参考程度に書く。

今作からイーブイの声が悠木碧のものになった。これは第八世代でも継続される。

アメ

カブイは一応初代のピカチュウバージョンリメイクしたゲームという体裁だが

ポケモンGOとの連動を強く意識したゲームで、システムにもポケモンGOの影響がある。

ポケモンGOではポケモン博士研究所に送ったときにもらえるアメでポケモンを強化するが、

カブイでも同じようにアメをもらえ、ポケモンレベルとは別に強化できる。

これは本編では導入されなかったが、第八世代では経験値アメという似て非なるアイテムが導入された。

経験値アメはその名の通り経験値が入る。

ポケモンGOっぽいポケモンゲット方式

ポケモンGOでのポケモンゲットはタッチパネルを使ってボールを投げるの方式だったが、

カブイでもそれっぽい方式になっている。

カブイではSwitchJoy-Conを使って投げる動作を行うこともできる。

でも面倒なのでSwitch携帯モードボタンを押す方式のゲット方式にする人が多いと思う。

ポケモンの入れ替えがどこでもできるようになった

今まではポケモンセンターに行かなければパーティを編成できなかったが、

カブイではポケモンセンター外でもポケモンの入れ替えが可能になった。

この仕様変更ソードシールドにも引き継がれている。

第八世代(ソードシールド、BDSP(ダイパリメイク)):Switch

舞台はガラル地方(イギリスモチーフ)。

現在の最新世代。

ダイマックスの導入

メガシンカZワザ廃止された代わりに導入された戦闘中1度だけ使える特殊システム

ポケモンが数ターン巨大化して、その間はわざも「ダイマックスわざ」に変化する。

どのポケモンで、どのタイミングダイマックスを切るかという駆け引き結構好評だったと思う。

また、ポケモンによっては「キョダイマックス」という特別なすがたに変化して、

わざも通常のダイマックスわざとは違う「キョダイマックスわざ」を使うことができる。

システム的にはメガシンカとZわざの折衷のような仕組み。

DLCの導入

今回はエメラルドプラチナウルトラサンムーンのようなマイナーチェンジは発売されなかったが、

その代わりに有償の追加ダウンロードコンテンツとして「鎧の孤島」と「冠の雪原」が遊べるようになった。

前回のウルトラサンムーンが「DLCみたいな内容なのにフルプライスなのはおかしい」と言われていたし、

金も2000円ちょっとで以前と比べてかなり良心的になったと個人的には思う。

オープンワールドフィールドワイルドエリア

ガラル地方にはワイルドエリアというオープンワールドフィールドがある。

ポケモンシンボルエンカウントとなったがあくまオープンワールド「風」なので

別にポケモンに襲われて死ぬ事は無い。後述のアルセウスでは死ぬ

マックスレイドバト

ワイルドエリアにあるポケモンの巣から光の柱が出ているときに、

巣の中にいるダイマックスポケモンと戦うことができる。

倒せばそのポケモンを捕まえるチャンスが与えられ、またいろんなアイテムも手に入る。

これがまた大縄飛びを面倒臭くしたようなゲームで、正直面白くなかったんだよね…

DLC「冠の雪原」で歴代伝説のポケモン出会うチャンスもあるダイマックスアドベンチャーも追加された。

リージョンフォーム独自の追加進化の登場

サンムーンで初登場したリージョンフォームだが、

今回はさらリージョン独自進化を果たすポケモンも現れた。

例えばルビサファで初登場した「マッスグマ」にはガラルのすがたがあるけれど、

(設定上ではガラルのマッスグマ原種なのだという)

そこからさらに「タチフサグマ」というポケモン進化するようになった。

まり従来のマッスグマには進化が与えられないわけだ…そこはちょっと悲しいね

ちなみに伝説のポケモンリージョンフォームが登場したのも第八世代で、

初代に登場したファイヤーサンダー・フリーザーリージョンフォームが登場した。

登場ポケモンリストラ

サンムーンまでに809種類ものポケモンが追加されてしまったので、いよいよ限界が来てしまった。

ポケモンは開発期間がビジネス上の都合で制約がある(ゼルダのように4年も5年も開発期間を裂けられない)ため

全てのポケモンを新しい作品に連れて行くことは今後できないという話だ。

例えばサンムーンで初登場した「ネッコアラ」は最新作の剣盾やアルセウスには連れて行けない。

ただ、リストラされてもポケモンHOMEのようなクラウドサービスには残せておけるため

今後リストラされたポケモンが復活するまでHOMEで寝かせることはできる。

とくせいパッチとせいかく変更ハーブ

とくせいパッチ使用するとポケモンのとくせいを隠れとくせいに変更できるようになった。

また、ハーブ性格ステータス補正を別の性格のものに変更できるようになった。

これらによって厳選難易度が落ちた。

正直、とくせいパッチしろハーブしろもっと早く実装して欲しかった要素だ。

俺はそういうの疲れちゃったからポケマスやってるよ。

わざレコードの導入

第五世代わざマシン何度でも使えるようになったが、

使い捨てわざマシンがわざレコードとして再び導入された。

わざレコードマックスレイドバトルなどで手に入れることができる。

もちろん何度でも使えるわざマシンも今まで通りある

第8.5世代(アルセウス):Switch

舞台ヒスイ地方(過去シンオウ地方)。

Pokémon LEGENDS アルセウス」は今のところポケモン本編最新作だが、

従来のシリーズとは大きく違っているため便宜的に8.5世代とする。

今作でピカチュウイーブイの声が電子音に戻った。

次回作スカーレットバイオレットでも電子音継続されるらしい。

3Dアクション

なんと今回はポケモン戦闘に入るまでが3Dアクションとなっている。

モンスターボール自分で狙って捕まえられ、相手が気づかないうちに遠くから狙い獲ることもできる。

ただしポケモンプレイヤーを襲うし、プレイヤーの体力が尽きると持っていたアイテムフィールドに落としてしまう。

他の人も言っているかもしれないが全体的にモンハンっぽい。

ヒスイ最初出会うラベン博士も「ポケモンは怖い生き物です!」と言っている。

オヤブンと呼ばれるオーラをまとったポケモン特に強く、プレイヤーはかいこうせんを撃ってくるものもいる。

がんばりのいし

カブイのアメのシステムちょっと洗練させたもの

ポケモンを逃がしたり捕まえたりすると通称ガンバアイテムと呼ばれるアイテムをもらえる。

今作のポケモンにはガンバレベルという個体値的なパラメータが設定されているのだけれど、

ガンバレベルガンバアイテムを与えていくと最終的にMAX(10)まで上昇する。

従来の個体値努力値(ポケモンを倒すと取得できるいわゆる基礎ポイント)を統合させたような仕組みで、

今後はこれでもういいんじゃねえかという気持ちになってくる。

 

他にもいろいろあるけど、正直書き切れないわ。勘弁してくれ。

今日一日一連のポケモン記事だけで2万字も書いて疲れた

2022-04-27

anond:20220427115511

韓国様が強すぎるからよそのリージョンでも韓国傭兵が暴れてるんだ リーグオブ韓国だよ

去年はでかい大会2つ中国に取られたけど

2022-04-19

anond:20220419222221

日本人が」なんて増田には一言も書いてないけど誰にキレてるの?

リージョンを区切ってるのは大会運営側だし、「そういうくっだらねえ国境線で仕切られた世界から卒業するのがオンラインゲーム目標」って誰の目標?初めて聞いたけど。

多分fpsエアプだと思うけど、本気で全世界の人が同じ環境プレイできると思ってる?fpsでどれだけping重要かわかってる?コロナ禍にも関わらずオフライン大会が開催され、観客もオフラインを望んでる意味わかってる?

君みたいに暴言吐く人がいるせいでEsports全体のイメージが悪くなるから、本当にゲーム界隈のことを考えてるならネット発言しないで欲しいな。

2022-03-11

anond:20220311224328

わりとまあ悪とは何か、冷戦は間違いだったあそこで共産主義は徹底的に滅ぼすべきだったってなっちまうよな

基本設計の違うリージョン同士がなあなあでやってきてんだからこうならない努力にこそ全力を注ぐべきだったんだけど人間どっちが正しいかで結局戦争になるんだな

2022-02-18

VMWare苦しい戦いしてるなー

まあVMWorldとかで10年以上人生の春を謳歌してきたからもう十分やろ

お疲れさん

マルチクラウド環境における5つの課題とは

VMware提案する、DRにも対応するマルチクラウドソリューション

昨今のCOVID-19流行への対応やDXを推進する中で、クラウドサービスの利用はビジネススピードの加速や柔軟なシステム運用効果的であり、従来のオンプレミス環境と併用するハイブリッド環境や、複数クラウドを利用するマルチクラウド環境が増えている。一方で、これらの環境を維持していくには課題も多く、セキュリティリスクも増大してしまう。ここでは、こうした課題解決するVMwareソリューションを紹介する。

マルチクラウド環境における5つの課題

COVID-19流行への対応やDX(デジタルトランスフォーメーション)のためのビジネス変革が進む中で、ビジネススピードの向上やニーズに対する迅速で柔軟な対応がこれまでになく求められている。これらを実現するために、アプリケーションの変革やクラウドへの移行が加速している。

多くの企業が、「ビジネススピード対応できるモダンアプリケーション」や、「あらゆるクラウドデータセンター、エッジでビルドおよび実行が可能であること」、「エンタープライズクラスレジリエンスセキュリティ運用の実現とビジネス変革」がDXを実現するために必要であると考え、これらを実現するためにマルチクラウド環境活用が前提になってきている。

具体的には、Amazon Web Services(AWS)、Microsoft Azure(Azure)、Google Cloud Platform(GCP)といった複数パブリッククラウドサービスを併用し、適材適所で使い分けているのが現状であろう。しかし、マルチクラウド環境では解決必要課題存在する。その課題とは、「ワークロードのシームレスな移行・連携」、「クラウドごとのスキル習得」、「運用管理簡素化」、「セキュリティリスクの低減」、「最適なコスト管理」の5つである。この5つがクラウド利用の理想現実ギャップとなっており、これらを意識して進めていく必要がある。

マルチクラウド環境における5つの課題

特にマルチクラウド環境適材適所で使う場合クラウドごとに利用する技術が異なるため、設定項目や内容に違いがあり、その設定ミスによるインシデントも発生している。重大な影響を及ぼす場合もあるため、それぞれのクラウドを扱う際のスキル重要になる。

VMware Cloud on AWSの特長とメリット

こうしたマルチクラウド環境における課題解決するには、一貫性のあるクラウドインフラストラクチャ、および運用管理サービス重要ポイントとなる。例えばVMwareは、複数パブリッククラウドだけでなくオンプレミスを含むハイブリッドクラウド環境においても、仮想的なレイヤーを構築することで管理運用を一元化している。

VMware Cloud on AWSは、VMwareAWSが共同で開発したもので、AWSベアメタルサーバー上にvSphere、NSX、vSAN、vCenterを導入し、ホスト専有型のクラウドサービスとして提供するものだ。

VMware Cloud on AWSの特長

その特長は3つある。1点目は「VMware製品ベースとしたクラウドであること。VMware製品仮想化されているため、AWS世界にいながらオンプレミス環境で利用していたスキルセットや運用管理ツールを利用でき、新たなスキル習得する必要がない。

2点目は「シームレスクラウドに移行できる」こと。ワークロードをオンプレミス環境から無停止で移行することができる。アプリケーションを更改する必要もないため、クラウドに移行する時間コストリスクを大幅に削減することが可能だ。

3点目は「VMware管理を行う」こと。ハードウェアソフトウェアトラブル対応運用管理メンテナンス対応など、すべてサービスの中でVMware実施する。3カ月に一回の頻度で新しいリリース提供しており、ユーザー要件を反映しながら新たな機能を追加している。

最近アップデートの大きなものとして、日本で第2のリージョンとなる大阪リージョンを設置し、サービス提供を開始したことが挙げられる。例えば西日本地区データセンターを持つユーザーは、より低遅延でサービスを利用できるようになった。昨今は感染症流行地震の発生などによってBCPを見直すユーザーが増え、VMware Cloud on AWSリカバリサイトとして利用するケースも増えている。その意味でも、大阪リージョン活用度が高いといえる。

大阪リージョンサービス提供開始

VMware Cloud on AWSが選ばれる理由は、大きく3つ挙げられる。1点目が既存ノウハウ運用管理手法をそのまま踏襲できるという点。VMware製品ベースとしたクラウドサービスであるため、オンプレミス環境における管理者のスキル運用ノウハウなど、既存資産をそのままクラウド上でも活用でき、新たなスキル習得や、運用管理手法の大きな変更の必要もない。クラウドオンプレミス環境をvCenterから一元管理できる。

VMware Cloud on AWSが選ばれる理由

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 Tanzuの概要

高まるDR環境へのニーズ安価に実現

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の活用課題解決するだけでなく将来への有効投資となる。企業規模や業種に関係なく検討すべきソリューションといえるだろう。

2022-01-25

本のまとめ

--

この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。

1章

コンテナとは】

他のプロセスとは隔離された状態OS上にソフトウェアを実行する技術

コンテナ利用のメリット

環境依存から解放

コンテナにはアプリの稼働に必要となるランタイムライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリ依存関係をすべてコンテナ内で完結できる。

依存関係を含めたパッケージリリース単位となる

環境構築やテストに要する時間の削減

優れた再現性ポータビリティ

全ての依存関係コンテナ内で完結するため、オンプレでもクラウドでも起動する。

ステージング環境テスト済みのコンテナイメージプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテスト必要工数を削減できる。

リソース効率のアップ

サーバー仮想化では、仮想マシンレベルリソースを分離し、ゲストOS上でアプリが起動する。つまりアプリだけでなく、ゲストOSを動かすためのコンピューティングリソース必要

一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。

Dockerとは】

コンテナライフサイクル管理するプラットフォーム

アプリコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。

アプリソースコード + Dockerfile

↓ buildでイメージ作成

イメージ(アプリケーションと依存関係パッケージングされる。アプリライブラリOS)

shipイメージの保存

レジストリに保存

run コンテナの実行

オンプレクラウドなどで起動

Dockerfileとは】

イメージを構築するためのテキストファイル

このファイルコマンド記述することで、アプリ必要ライブラリインストールしたり、コンテナ上に環境変数を指定したりする。

1章まとめ、感想

コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンド設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。

2章

AWS提供するコンテナサービス

コントロールプレーン

コンテナ管理する機能

コントロールプレーンは2種類

ECSとEKSがある。

ECS

フルマネージドなコンテナオーケストレータ。

オーケストレーションサービスであり、コンテナの実行環境ではない。

ECSの月間稼働率99.99%であることがSLA として保証

タスク

コンテナ動作するコンポーネント

タスクは1つ以上のコンテナからなる

アプリを起動するためにはコンテナ必要

タスク定義

タスク作成するテンプレート定義JSON記述

デプロイするコンテナイメージタスクコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。

サービス

指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサータスクを実行するネットワーク指定

クラスター

サービスタスクを実行する論理グループ

データプレーン

コンテナが実際に稼働するリソース環境

2種類ありECSとFargateがある。 Fargateに絞って書く

Fargateとは

サーバーレスコンピューティングエンジン

AWSのフルマネージドなデータプレーンとして定義されている

コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する

Fargate メリット

ホスト管理不要であること

サーバーのスケーリングパッチ適用保護管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる

Fargate デメリット

価格EC2より高い。

利用者コンテナの稼働するOSには介入できない

コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる

ECR

フルマネージドなコンテナレジストリ

コンテナイメージを保存、管理できる

コンテナが利用されているサービス

Lambda

・App Runner

Lambda

 利用者コードアップロードするだけでコードを実行できるサービス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の登場からしばらく経過し、有識者経験者は増え、確保しやすい。

システム要件確認

多数のユーザーに使ってもらう

可用性を高めるためにマルチAZ構成を取る

CI/CDパイプライン形成し、アプリリリースに対するアジティを高める

レイヤで適切なセキュリティ対策不正アクセス対策認証データの適切な管理ログ保存、踏み台経由の内部アクセス)を施したい

2章まとめ、感想

AWS提供するコンテナサービスはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理不要インフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である

3章

この章では運用設計ロギング設計セキュリティ設計信頼性設計パフォーマンス設計コスト最適化設計について述べている。

運用設計

Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計不具合修正デプロイリスク軽減のためのCI/CD設計必要である

モニタリングとは

システム内で定めた状態確認し続けることであり、その目的システムの可用性を維持するために問題発生に気づくこと

オブザーバビリティとは

システム全体を俯瞰しつつ、内部状態まで深掘できる状態

オブザーバビリティの獲得によって、原因特定対策検討が迅速に行えるようになる

ロギング設計

・cloud watch logs

他のAWSサービスとの連携も容易

サブスクリプションフィルター特定文字列の抽出も容易

・Firelens

AWS以外のサービスAWS外のSaaS連携することも可能

Firehoseを経由してS3やRed shiftOpenSearch Serviceにログ転送できる

Fluentdやfluent bit選択できる

fluent bitを利用する場合AWS公式提供しているコンテナイメージ使用できる

セキュリティ設計

イメージに対するセキュリティ対策

 - ソフトウェアライブラリ脆弱性は日々更新されており、作ってから時間が経ったイメージ脆弱性を含んでいる危険がある。

 - 方法

  脆弱性の有無はECRによる脆弱性スキャンOSSのtrivyによる脆弱性スキャン

継続的かつ自動的コンテナイメージスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリ場合CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャン必要になる。

cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能

提供元が不明ベースイメージ使用は避ける

・IAMポリシーによるECRのパブリック化の禁止

 - オペレーションミスによる公開を防ぐことができる

信頼性設計

マルチAZ構成

Fargateの場合サービス内部のスケジューラが自動マルチAZ構成を取るため、こちらで何かする必要はない。

障害時切り離しと復旧

ECSはcloud watchと組み合わせることでタスク障害アプリエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる

ALBと結びつけることで、障害が発生したタスク自動で切り離す

リタイアという状態

AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合ECSは新しいタスクに置き換えようとするその状態のこと。

Fargateの場合アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ整合などが生じて危険

システムメンテナンス時におけるサービス停止

ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能

サービスクォータという制限

意図しない課金増加から保護するために設けられた制限

自動でクォータは引き上がらない

cloud watch メトリクスなどで監視する必要がある。

パフォーマンス設計

パフォーマンス設計で求められることは、ビジネスで求められるシステム需要を満たしつつも、技術領域進歩環境の変化に対応可能アーキテクチャを目指すこと

ビジネス上の性能要件を把握することが前提

利用者数やワークロードの特性を見極めつつ、性能目標から必要リソース量を仮決めする

FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める

既存のワークロードを模倣したベンチマークや負荷テスト実施してパフォーマンス要件を満たすかどうかを確認する

スケールアウト

サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存タスクを停止する必要原則ない。

スケールアウト時の注意

・Fargate上のECSタスク数の上限はデフォルトリージョンあたり1000までであること。

VPCIPアドレスの割当量に気をつける

ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能IPアドレスが消費されていく

スケールアウトによるIPアドレスの枯渇に注意

Application Autoscaling

Fargateで使用可能

Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う

ステップスケーリングポリシー

ステップを設けて制御する

CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意ステップに従ってタスク数を増減させる

ターゲット追跡スケーリングポリシーとは

指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針

ターゲット追跡スケーリングPermalink | 記事への反応(0) | 21:45

本のまとめ

--

この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。

1章

コンテナとは】

他のプロセスとは隔離された状態OS上にソフトウェアを実行する技術

コンテナ利用のメリット

環境依存から解放

コンテナにはアプリの稼働に必要となるランタイムライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリ依存関係をすべてコンテナ内で完結できる。

依存関係を含めたパッケージリリース単位となる

環境構築やテストに要する時間の削減

優れた再現性ポータビリティ

全ての依存関係コンテナ内で完結するため、オンプレでもクラウドでも起動する。

ステージング環境テスト済みのコンテナイメージプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテスト必要工数を削減できる。

リソース効率のアップ

サーバー仮想化では、仮想マシンレベルリソースを分離し、ゲストOS上でアプリが起動する。つまりアプリだけでなく、ゲストOSを動かすためのコンピューティングリソース必要

一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。

Dockerとは】

コンテナライフサイクル管理するプラットフォーム

アプリコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。

アプリソースコード + Dockerfile

↓ buildでイメージ作成

イメージ(アプリケーションと依存関係パッケージングされる。アプリライブラリOS)

shipイメージの保存

レジストリに保存

run コンテナの実行

オンプレクラウドなどで起動

Dockerfileとは】

イメージを構築するためのテキストファイル

このファイルコマンド記述することで、アプリ必要ライブラリインストールしたり、コンテナ上に環境変数を指定したりする。

1章まとめ、感想

コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンド設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。

2章

AWS提供するコンテナサービス

コントロールプレーン

コンテナ管理する機能

コントロールプレーンは2種類

ECSとEKSがある。

ECS

フルマネージドなコンテナオーケストレータ。

オーケストレーションサービスであり、コンテナの実行環境ではない。

ECSの月間稼働率99.99%であることがSLA として保証

タスク

コンテナ動作するコンポーネント

タスクは1つ以上のコンテナからなる

アプリを起動するためにはコンテナ必要

タスク定義

タスク作成するテンプレート定義JSON記述

デプロイするコンテナイメージタスクコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。

サービス

指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサータスクを実行するネットワーク指定

クラスター

サービスタスクを実行する論理グループ

データプレーン

コンテナが実際に稼働するリソース環境

2種類ありECSとFargateがある。 Fargateに絞って書く

Fargateとは

サーバーレスコンピューティングエンジン

AWSのフルマネージドなデータプレーンとして定義されている

コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する

Fargate メリット

ホスト管理不要であること

サーバーのスケーリングパッチ適用保護管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる

Fargate デメリット

価格EC2より高い。

利用者コンテナの稼働するOSには介入できない

コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる

ECR

フルマネージドなコンテナレジストリ

コンテナイメージを保存、管理できる

コンテナが利用されているサービス

Lambda

・App Runner

Lambda

 利用者コードアップロードするだけでコードを実行できるサービス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の登場からしばらく経過し、有識者経験者は増え、確保しやすい。

システム要件確認

多数のユーザーに使ってもらう

可用性を高めるためにマルチAZ構成を取る

CI/CDパイプライン形成し、アプリリリースに対するアジティを高める

レイヤで適切なセキュリティ対策不正アクセス対策認証データの適切な管理ログ保存、踏み台経由の内部アクセス)を施したい

2章まとめ、感想

AWS提供するコンテナサービスはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理不要インフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である

3章

この章では運用設計ロギング設計セキュリティ設計信頼性設計パフォーマンス設計コスト最適化設計について述べている。

運用設計

Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計不具合修正デプロイリスク軽減のためのCI/CD設計必要である

モニタリングとは

システム内で定めた状態確認し続けることであり、その目的システムの可用性を維持するために問題発生に気づくこと

オブザーバビリティとは

システム全体を俯瞰しつつ、内部状態まで深掘できる状態

オブザーバビリティの獲得によって、原因特定対策検討が迅速に行えるようになる

ロギング設計

・cloud watch logs

他のAWSサービスとの連携も容易

サブスクリプションフィルター特定文字列の抽出も容易

・Firelens

AWS以外のサービスAWS外のSaaS連携することも可能

Firehoseを経由してS3やRed shiftOpenSearch Serviceにログ転送できる

Fluentdやfluent bit選択できる

fluent bitを利用する場合AWS公式提供しているコンテナイメージ使用できる

セキュリティ設計

イメージに対するセキュリティ対策

 - ソフトウェアライブラリ脆弱性は日々更新されており、作ってから時間が経ったイメージ脆弱性を含んでいる危険がある。

 - 方法

  脆弱性の有無はECRによる脆弱性スキャンOSSのtrivyによる脆弱性スキャン

継続的かつ自動的コンテナイメージスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリ場合CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャン必要になる。

cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能

提供元が不明ベースイメージ使用は避ける

・IAMポリシーによるECRのパブリック化の禁止

 - オペレーションミスによる公開を防ぐことができる

信頼性設計

マルチAZ構成

Fargateの場合サービス内部のスケジューラが自動マルチAZ構成を取るため、こちらで何かする必要はない。

障害時切り離しと復旧

ECSはcloud watchと組み合わせることでタスク障害アプリエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる

ALBと結びつけることで、障害が発生したタスク自動で切り離す

リタイアという状態

AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合ECSは新しいタスクに置き換えようとするその状態のこと。

Fargateの場合アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ整合などが生じて危険

システムメンテナンス時におけるサービス停止

ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能

サービスクォータという制限

意図しない課金増加から保護するために設けられた制限

自動でクォータは引き上がらない

cloud watch メトリクスなどで監視する必要がある。

パフォーマンス設計

パフォーマンス設計で求められることは、ビジネスで求められるシステム需要を満たしつつも、技術領域進歩環境の変化に対応可能アーキテクチャを目指すこと

ビジネス上の性能要件を把握することが前提

利用者数やワークロードの特性を見極めつつ、性能目標から必要リソース量を仮決めする

FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める

既存のワークロードを模倣したベンチマークや負荷テスト実施してパフォーマンス要件を満たすかどうかを確認する

スケールアウト

サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存タスクを停止する必要原則ない。

スケールアウト時の注意

・Fargate上のECSタスク数の上限はデフォルトリージョンあたり1000までであること。

VPCIPアドレスの割当量に気をつける

ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能IPアドレスが消費されていく

スケールアウトによるIPアドレスの枯渇に注意

Application Autoscaling

Fargateで使用可能

Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う

ステップスケーリングポリシー

ステップを設けて制御する

CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意ステップに従ってタスク数を増減させる

ターゲット追跡スケーリングポリシーとは

指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針

ターゲット追跡スケーリングPermalink | 記事への反応(0) | 21:45

2021-12-29

戦争が始まったら使えなくなるネットサービスってあるんだろうか

データとしては国内リージョンにあってもサービス維持できないとか。

2021-10-22

Windows subsystem for Android提供開始とか日本語記事が出回ってるけどこれUSリージョンAmazonアカウント向けで提供してるだけだから結構無意味

そこを理解していないのか、リージョン言及してない記事がちらほらあるので不誠実だなと思う

2021-09-23

surface go日本版がまた冷遇されてる

いつものように高いしラインナップ制限されてる。

リージョン選べないので米amazonに並ぶまで我慢だな。

2021-05-27

金融機関向けシステムのDX成功事例について

1部システムGCPに移行しました というとGCPが狙われるので

失敗したというとじゃぁAWSが怪しいといわれるから

どうやったら成功事例なんか、金融リージョンで言えるのかが謎

2021-02-20

anond:20210219052405

インターネット破壊する」って具体的にどうするんだろう

そこらのIX破壊しただけじゃ多重化してるから無理だよな

AWSに狙いを絞るのもいいけど、多数のリージョンをすべて同時に破壊しないと意味がない

DNSルートサーバーも多重化されてるから全部を同時に破壊しないといけない

だれか教えてくれ

2020-12-30

たとえば ある情報を僕たちが言わないではなく あるひとたちには言わないようにすることをネットでやった場合

なぜそれが検閲ではないのか?

おれはたまたま いま Amazon縛りで 可能な限りAmazonからとらないようにしているんだが

 

特約店で 全員に対してなら しょうがない

 

ある特定個人に対してのみ ある商品は紹介しないとなった場合

理由をお伺いしたい

 

キャンペーン中だから リージョンから それはいいけど 

 

意地になりまいした そうですか すでに離婚が1件以上

ちなみに 復縁は無理でしょう 再婚したはずです

 

僕にも特定団体は ビジネスではお付き合いさせていただくものプライベートはご遠慮いただくことが多いとかは そりゃあります

2020-12-12

anond:20201212113754

2018年とまったのはEC2とか使ってサーバーレスにしてないとこだけやで

ワイの会社東京リージョンやが完全サーバーレスなのでその時も無停止や

あと料金も10万以上ユーザーいても月数万や

2020-10-15

動くサザエさん

最近ドラッグストアに並び始めた動くサザエさんだけど、作りが甘いせいか、使ってるうちに首のところがグラグラしてきて走行中に吹っ飛ぶことが4回あった。日本中国と同じ東アジアリージョンから髪型が左右反転してないし、そこだけは良かったんだけどね。

2020-07-09

日本担当チームではなく

日本リージョンサーバ担当チームなんだよなぁ 国を担当してもらっているわけではない

日本にあるサーバ担当してもらってる

日本担当チームではなく

日本リージョンサーバ担当チームなんだよなぁ 国を担当してもらっているわけではない

日本にあるサーバ担当してもらってる

2020-06-11

蓮舫サーバやすとかじゃなくて時代クラウドなんですよ!」

蓮舫Auto-Scalingしてなかったんですか?普通は別リージョンインスタンス立ち上げてELBで割り振りますよね?」

2020-05-25

[]5月25日

ご飯

朝食:サンドイッチ。昼飯:おにぎり。夕食:人参大根とたまとネギの炒め物。ご飯納豆。間食:ハバネロ味のスナック菓子

調子

むきゅーはややー。仕事はどっさらん。

ポケモン

マックスレイド周回。そろそろDLC来ると思うと、モチベが上がってきた。

DLCの主役級のポケモンウーラオスが悪タイプフォルムもあるので、そこら辺も楽しみ。

それ以外にもリージョン新規もあるのかしら? 既存ポケの入国も気になるし、滾る!

○ポケマス

タイプで戦うエンテイイベントがあるらしいので、水タイプを育ててた。

このゲーム、解析とかされてるんだね。どうも僕の愛する悪タイプポケモントレーナー実装されるらしくウキウキしている。一応天井できるので安心

……今ふとコマスター10回ぐらいEXと交換できるアイテム貯めたままサービス終わったの思い出して悲しくなった。

マリオ64(WiiUVC)

スター5個。累計60個集めるまでプレイ

難易度が上がってきた……

ログイン ユーザー登録
ようこそ ゲスト さん