■
お疲れ様です。
最近睡眠不足が顕著に出ており、仕事に遅刻しない程度の寝坊が増えているので今日はアウトプットのみにして、睡眠時間の確保をしたいと思います（執筆時点午前0時半頃）。
さて、前回はクラウドでシステムを設計する際の設計思想や、耐故障性の高いシステムを構築する際に用いられる考え方や手法について学んだ内容のアウトプットをしました。今回はその続きからになります。
前回はシステムの耐故障性についての話が中心でしたが、今回はAWSなどのクラウドを使用する利点の1つについて具体的に学習しました。
クラウドでは、『弾力性』という今までになかった概念をインフラストラクチャに取り入れました。弾力性はまた伸縮性とも呼ばれ、状況に応じてリソースの性能を柔軟にスケールイン、スケールアウトします。この弾力性は以下の3つの方法によって実現されています。
1つ目は巡回スケーリング。日毎や週ごと、月ごとなどの定期的にスケーリングすることを言います。
2つ目はイベントベーススケーリング、事前にトラフィックの急激な増加が予想される際に実施されるスケーリングの事を言います。トラフィックの増加が予想される時間帯に自動的にスケールアウトをする、スケジュールドスケールアウトパターンを利用しており、オンラインゲームやショッピングサイトなどの、時間帯でアクセスに偏りのあるシステムに有効です。
3つ目はオンデマンドの自動スケーリング、監視サービスを利用することにより、監視項目に基づいてトリガーを送信し、スケールイン・スケールアウトをします。こちらはスケールアウトパターンを利用しており、トラフィックの増加を自動的に検知してスケールアウトを行います。突発的であっても対応可能であり、実用性やシステム性能を維持できます。
クラウドではこういった弾力性を利用して、必要に応じたリソースの増減が可能です。必要な時にリソースを追加し、不要になれば廃棄する、使い捨てのような形でビジネスリソースをAWSでは利用可能になります。
今回は従来のオンプレミスにはなかった、クラウドならではのシステムの柔軟性について学びました。オンプレミスではどうしても常に最大ピーク時について考える必要があり、機材などもそれに応じたものを用意する必要がありました。ですがクラウドを利用すれば必要な時に必要な分だけ性能を求めることが可能になります。
今回はアウトプットのみでインプットをしないので次回の更新は明後日になります。
毎回になりますが、もし識者の方が読んでいましたら、解釈が違う点や補足等をコメントでいただければ幸いです。
では、また次回。
AWS学習 2日目
お疲れ様です。
3日くらい開いてしまい、早速毎日やるというところが崩れつつありますが、時間はありますのでのんびり進めていきます。
前回はクラウドとオンプレミスの違いと、AWSを利用するメリットについて学習しました。今回は実際にシステムを構築するにあたって、どのような設計原理を用いているのか、多少日にちが空いてしまっていますがアウトプットしていきます。
前回同様、もし識者の方がこの記事を読んでいましたら、解釈の違い等あればご指摘いただけると幸いです。
まず、システムを構成するうえで重要になるのが、何かしら不具合があった際の対応です。オンプレミスでもクラウドでも、機材やソフトの故障や、災害によるトラブルは人が作ったものである以上つきものです。
ではどうやってそれらと向き合っていくのか。そのためには根本的な部分から考え直す必要があります。『トラブルがあってから対応』するのではなく、『予め起こりうるトラブルを想定』するのです。トラブルが発生した際、それに対処・処理をするメカニズムを予め組み込んでおくのです。
これをDesign for Failure、故障に備えた設計と言います。そのままですね。実に単純です。Design for Failureを採り入れた設計をすることで、耐故障性の高いアーキテクチャ*1を構築することができます。
実現するためには、まず単一障害点という、障害の起こりうるポイント1つ1つに予め対処することが必要になります。
耐故障性の高い設計をするための理想をこれまで述べてきましたが、では実際にクラウドではどのような手法が用いられているのでしょうか。
基本的にクラウドではサービス指向アーキテクチャの設計原則を踏襲しています。サービス指向アーキテクチャとは、個別のコンポーネント*2の集合体で1つのシステムを構成することを言います。つまり、それぞれ独立した要素１つ１つの集合体で１つのシステムを形作っていくようなイメージで、たとえ1つのコンポーネントが何らかの理由で停止してしまった際に、他のコンポーネントでそれを補う事で、まるで何もなかったかのように作業を継続することが可能となります。
そしてそれを実現するためには、コンポーネント1つ1つの疎結合が重要になります。疎結合とは、システム上のアプリケーションを構成するレイヤーやコンポーネント1つ1つを隔離し、依存しあわない形で構築することを言います。例えばWebアプリケーションの場合、Webサーバやアプリケーションサーバ、データベースといった形でそれぞれが直接的な関わりを持たない形で構成成分を隔離することができます。
ですが、隔離されていて機能的な依存性はないとは言いつつも、お互いがお互いに相互作用するような関係性は形成されています。1つ1つが他方のブラックボックス*3として存在している状態になるのです。なので、1つが停止してしまっても、ある程度の機能は補うことが可能になります。
またこういった形で分離化を実現するには、Amazon SQS（Single Queue Service)を使ったキューイングチェーンを利用します。それぞれのキューは処理が完了するまでデータが残っているので、仮に処理中のリソースに障害が発生してもチェーン内にある他のリソースを使用することで処理の継続が可能となります。利用することで、それぞれが同期や依存はしていないものの、お互いがお互いを補うことのできる、疎結合のコンポーネントを構成することが可能なのです。
今回はここまでです。要するにシステムを設計するときには、大黒柱1本で支えようとするのではなく、短い間隔で柱を大量に用意した方が安全だよね、安心だよね、という理屈というわけですね（解釈違いかもしれませんが）。
色々初めて触れる単語や考え方が多かったので、テキストの内容をほぼ書き写したような内容にはなってしまっていますが、元々テキストが学習の要点をまとめたものですので、むしろそのまま理解する方が結果的には良いのではと思います。
明日からはまた毎日更新に頑張って戻したいと思いますので、もし読んで頂いている方がいらっしゃいましたら、応援の程よろしくお願いいたします。
まだまだインフラエンジニアとしての道のりが長いように感じますが、1歩ずつ確実に踏み出していきたいですね。
ではまた明日。
AWS学習 1日目
昨日からAWSの勉強を始めまして、これから毎日少しずつ学習を始めていこうと思っている所です。
それに際して、毎日前日の内容をアウトプットする時間を設けることにしましたので、そのアウトプットの場としてこのブログを活用しようと考えました。
当初このブログを開設した時とは記事の趣向等が変わってはしまいますが、まぁ自分のブログなので、ってことでご勘弁いただきたいと思います。
また、もし有識者の方がこのブログを読んでいましたら、前日の学習内容を改めてまとめた内容を記事にしておりますので、間違った認識をしている箇所等がありましたらコメントは開放しておりますので、ぜひ教えていただければと思います。
最終的にはまずAWSのクラウドプラティクショナーの取得を目的としています。
では早速、昨日学習した内容について、自分で作ったノートを基にアウトプットをしていきます。
昨日はまずクラウドコンピューティングとは何ぞや、AWSとは何ぞやといったサービスそのものの概念を学習しました。
AWSとはクラウドサービスプラットフォームの一種であり、クラウドサービスプラットフォーム（以下クラウド）とは、インターネットを介してサーバー等のハードウェアやセキュリティなどのITリソースを間借りしシステムを設計・構築することで、従来までのオンプレミス（各種機材を自分で検討・調達しシステムの設計・構築する方法）では成しえなかった手軽さと低コスト化を実現したサービスのことを言います。
オンプレミスでは、機材の検討の時点でまずサーバーのピーク時パフォーマンスを考慮する必要があります。常に一定のアクセスがあるわけではないので、アクセス量の波を想定したうえで、更にピーク時のアクセス量やアクセス1件1件のデータ量を考慮し、それに耐えうる機材構成を検討する必要があります。
また機材を設置する場所や、それを維持・管理するための維持費ももちろん必要になります。常に最大ピーク時のキャパシティを考えなければならない以上、普段は使わない領域にも維持費はかかってしまいます。
一方AWSでは、まず機材を自分で用意する必要性がなくなるので、機材の調達費が必要なくなります。したがって機材を設置する場所を用意する必要もなくなります。また、維持費や管理費も利用料金に含まれているため、初期投資と維持費が比較にならないくらい安価になります。加えて使った分だけ利用料金のかかるオンデマンド（従量制課金）方式なので、最大ピーク時のパフォーマンスを考慮したサーバーのスケーリングも必要なく、必要に応じてスケーリングが可能になります。
また、オンプレミスの場合はITリソースを導入するのに数週間～数か月かかる場合が多いのですが、AWSでは数分単位で可能です。また、システム負荷やサービス拡充などに応じて柔軟な構成変更が可能です。
また新たにサーバーリージョンを設置したい場合にも、わざわざ現地に赴いて機材の手配や設置等もする必要がないので、わずか数分で世界中にデプロイすることが可能です。
最後に、使用しているテキストに記載のある、AWSの6つのメリットを紹介します。
1.固定費（設備投資費）が柔軟な変動費へ
2.スケールによる大きなコストメリット
3.キャパシティ予測が不要に
4.速度と俊敏性の向上
5.データセンターの運用と保守への投資が不要に
6.わずか数分で世界中にデプロイ
以上です。また明日、同じように今日学習した内容をアウトプットとして記事にしますので、もし今回の内容で解釈に間違いがありましたら、コメントにてご指摘いただけると幸いです。
では、また明日。
FF14 HUD研究その１
今回はFF14をプレイするにあたって、操作方法の1つであるキーマウ（キーボード＆マウス）操作やHUDについて、いろいろ考えたことを紹介したいと思います。
私の現在のデバイス環境はこんな感じ
↓
マウス:CORSAIR HARPOON RGB PRO
ｷｰﾎﾞｰﾄﾞ：RAZER BLACKWIDOW V3 黄軸
いきさつ
長らくPC版のFF14をXbox360コントローラーを使用して遊んでいましたが、実家を出たことを機にキーマウ操作に移行しました。（コントローラー持ってくるのめんどくさくて持ってこなかっただけ。なんかトリガーがキコキコうるさかったし。）
すでに実家を出て半年以上が経ち、3月に新しいPCを購入し、復帰してからも4か月程度経ちました。キーマウ操作に移行してから今まで、ずっとキーボードはキャラクター操作とターゲット操作に集中し、主にマウスでカメラ操作やアクションを頑張っていましたが、漆黒終盤あたりから通常のIDでも予兆範囲やギミックが激しくなってきたこともあり、ホットバー（アクションやスキルを置く場所）上を奔るマウスカーソルにだけ集中することが難しくなってしまいました。
そこで、心機一転キーマウに移行して初めてアクションもキーボードで操作できるようにしようと考えました。
前提として、FF14はデフォルトでホットバーにも対応するキーが設定されています。私はこれを「使わないし見づらくなる」という操作に適応しようともしない何とも怠惰の塊のような理由ですべての設定を解除していました。
一つ弁明させてほしいのですが、今までキーマウ操作で遊ぶようなゲームはFPSやTPS、RTS系の類しか遊んでおらず、コントローラー操作に対応したゲームはほぼすべてコントローラーで遊んでいたので、キーマウ操作と言えば『WASD操作+マウス』っていうのが個人的に鉄板だったのです。
そういう事情もあり、基本的にキーボードは移動のみ、ゲームによっては周辺のキーは持つ武器を変えるためだったりインベントリを表示するためだったりに使うこともありますが、基本的には左手の人差し指がD、中指がW、薬指がAといった、ＰＣゲーマー版のホームポジションに置かれていることが多く、隣接するQやE、R、Fや数字の1～4までは使うことはありましたが、それ以上はたまーーーーーーに使うか使わないかレベルでした。
もちろん、その程度の数のキーではFF14の操作量には耐えきることができません。まったくもって足りないのです。
だからと言って、数字の5以降なんて5はまだギリギリ指が届きますが、6以降は指がホームポジションから動いてしまうので使いづらくて仕方がありません。
ですからまず最初に、数字キーに依らない操作方法を模索することにしました。
キーバインド設定をどうするか
まず最初にそれぞれのホットバーに対応するキー設定を考えることから始めました。
1つのホットバーに登録できるアクションは12個、つまり最低ホットバーの為に最低12個のキーを設定する必要があります。
逆に言えば、この12個さえ決めてしまえばあとはShiftやCtrlとの同時入力によって数を盛ることができるので、最初にして最大の関門でもあるのです。
先ほども述べたように、私はキャラ操作もキーボードで行っているので、基本的に左手はホームポジションに固定されている状態です。その状態でも操作できるキーを12個探さなければなりません。ちなみにＱとＥはすでにターゲットの変更に割り当てているので一番身近なこの2つは使えません。
そこでまず浮上するのはFPSゲーマーであればかなりお世話になっているであろう数字の1～4とRとF、それからZXCといったキーです。これらは指をスッと動かすだけで操作が可能なので内定確実。早々に9個ものキーが決まってしまいました。こんなはずじゃなかった。
ですがまだ3つも決まっていません。続けてキーボードをまじまじと観察してみます。Fの隣のGキー。こいつはFPSゲームで手榴弾を投げる際などによく使われるキーです。多少指を開く必要こそありますが、割と頻繁に使われるので実際の操作でも特に違和感もありません。内定。
あと2つ。Gと同じような理論で行くとRの隣のTキーとCの隣のVキーが有力な候補キーです。Tはゲーム内のチャットに割り当てられていることが多いですね。友達いないから使わねぇけど。Vはぱっとしませんが、何かしらのショートカットが割り当てられていることはままあります。使ったことないから知らんけど。
他にも候補足るキーがないか探しましたが、特にありませんでした。仕方がないのでTとVも内定です。
ということで、ここまででアクション操作、もといホットバーの操作につかうキーが12個、無事に決まりました。内定者を見てみましょう。
・数字キー１～４
・RとT
・FとG
・ZとXとCとＶ
以上の彼らが今回の内定者に選ばれました。拍手。実際のキーボードと照らし合わせてみてもとてもよくまとまっていて、操作もし易そうです。
アクションの配置と操作練習
ここまででアクション操作に使うキーは決まったので、まず対応するホットバーにどのアクションを配置するのか、考えていきます。
私はもっぱらナイトというタンクロール（敵のヘイトを引き付けて味方を守る役割）に位置するジョブを使っており、使用する武器はファンタジーの王道である片手剣と盾です。
他のジョブと比べてもそこまで派手なことはしませんし、操作もシンプルな部類です。それでもレベルを最大まで上げるとアクションの総数は40近くになります。そんな数多くのアクションを的確に使い分けなければなりません。
難しいコンテンツになればなるほどその正確性はより高めなければならないので、使う頻度の高い、例えば敵を攻撃するアクションは操作しやすい場所に配置する必要があります。
『ファストブレード』というアクションがあります。敵単体を攻撃するアクションで、いくつかある敵単体を攻撃できるアクションの中で一番威力の低いものです。しかし、FF14には『コンボシステム』というものがあり、特定のアクションをした後に更に特定のアクションをすることで追加効果を得られたり威力が高まったりします。
この『ファストブレード』はこの後に『ライオットソード』というアクションにつながるようになっており、更に『ロイヤルアソリティ』や『ゴアブレード』といったアクションにつながります。つまり、これらのアクションはそれぞれの近くに配置してやる必要があります。
こんな感じでアクション1つ1つの関連性を考えて配置する必要があるので、キー設定を終えた後、その次の関門と言えます。
そんな感じで設定を終えたものがこちら↓
左から順番に、
・最初に設定したキーをそのまま押したときに発動するアクション
（使用頻度が多い攻撃用のアクションや防御バフ）
・Shiftキーと同時入力で発動するアクション
（↑ほど頻度は高くないが、それなりに使用するアクション）
・Ctrlキーと同時入力で発動するアクション
（使用条件があったり、する場面はあれど頻度は高くないアクション）
それぞれの共通の特徴として、1～4は攻撃アクションを割り当てています。
まだ暫定的なものではあるので、これから操作練習などのうちに変更することももちろんあると思いますが、現状はこんな感じ。
また、画面の端のほうにクリックして使う用のファストトラベルであったり、騎乗できるマウントだったりをクリックで使用できるよう配置しているホットバーがあるのですが、その近くに同じようにクリックで使用してフォローできるようにいくつかアクションを配置しています。
あとは練習と改良を重ねて、最終的にはエンドコンテンツ等にも挑めるようになりたいですね（願望）。
まとめ
一応これで戦闘の際に使うアクションの配置やキー設定は無事完了しました。
今回のものをいじっている途中で、戦闘用ではない、先ほどもちらっと述べたファストトラベルであったりを配置しているホットバーも色々配置したらいっぱいになっていたのが少し気になったので、次回はそれを何とかしたいと思います。
また、配置やキー設定についてアドバイス等ある方いましたらコメントにて教えていただければ幸いです。
それではまた次回。ありがとうございました。
はじめまして。
こんにちは。またはこんばんわ。
今回新しい趣味として、今までプレイしてきたゲームについての感想やレビューをブログとして公開してみようと思い、このブログを開設してみました。
ふと思いついただけですので、途中で更新が止まる可能性も大いにあります。
また、同じゲームについても日記のような形で何回も記述することもあると思います。
とりあえず、1日1本書くことを目標にちまちまできたらなと思っています。
100時間以上プレイしたものから10時間程度、またはそれ以下しか遊んでいないゲームについても記事にすることがあるので、記事の内容にとてつもない差が生まれることもあります。その点ご了承ください。
最初の記事を公開した時点ではあまりプレイできていなくても、それからまたプレイ時間を重ねることでレビューなどでの意見が変わることもあります。
そういったときはまた新しい記事を公開して、ある程度プレイしてからの感想などをまた書くと思うので、その時その時の内容の違いなどもお楽しみいただければなと思います。
筆者もゲーム購入の際に他人の意見をとても意識するタイプなので、同じような他の人の参考に少しでもなれればなと思います。
よろしくお願いいたします。
