Technical Terms

Github logo Edit on GitHub

技術用語のまとめ．

スケーラビリティ scalability

スケーラビリティとは，電子機器，ソフトウェア，システムなどの拡張性，拡張可能性のこと．スケーラビリティが高いことを「スケラーブルな scalable」と表現する．「スケーラブルなシステム」などと使う．

システムの利用や負荷の増大，用途の拡大などに応じて，どれだけ柔軟に性能や機能を向上，拡張できるかを表したもの．ソフトウェアの場合，小規模な機器やシステムから，大規模なものまで同じソフトで対応できることを意味する場合もある．

スケーリング scaling

スケーリングとは、（規模などの）増減，（面積などの）拡大縮小，などの意味を持つ英単語．一般の外来語としては「歯石のスケーリング」のように（汚れなどを）剥がしたり削り落としたりすることを表す場合もある．

情報システム分野での「スケーリング」

  • スケーリング：要求される処理量に合わせて，システムの性能や処理能力を増強したり縮減したりすること

情報システムの分野では，装置やソフトウェア，システムなどの性能や処理能力を，要求される処理量に合わせて増強したり縮減したりすることをスケーリングという．

スケールアップ / スケールアウト

スケーリング，とりわけシステムの性能，処理能力を高めるには 2 つの方法がある．「スケールイン（スケールアップ）」，「スケールアウト」である．

  • スケールイン（スケールアップ）
    • 機器単体の性能を向上させてシステムの性能，処理能力を高めること．
    • ex) サーバのメモリを増やす．CPU をグレードアップする．
  • スケールアウト
    • （サーバなどの）機器の稼働数を増やして処理を分散し，全体として処理能力を高めること．
    • ex) サーバの台数を増やす．

オンプレミス / クラウド on-premises / cloud

サーバ運用の方法 2 つ．

  • オンプレミス

    • コンピュータ（サーバ）を，自前の施設に設置・運用すること．
    • 規模を変更するには，物理的に機器や内部の部品などを増設あるいは削減しなければならないため，手間や時間がかかり，運用のコストが大きい．

  • クラウド

    • コンピュータ（サーバ）を，専門の事業者が運営する施設のコンピュータを必要なだけ借りて運用すること．規模の増減を柔軟かつ迅速に行うことができる．
      • Amazon/Amazon Web Service
      • Google/Google Cloud Platform
      • Microsoft/Microsoft Azure
      • Alibaba/Alibaba Cloud etc...

ロードバランサー load balancer, LB

サーバーレス serverless

認証 / 認可 authentication / authorization

「認証」と「認可」は密接に絡み合っている一方で全く別の概念である．理解が難しいのでまずざっくりと．

  • 認証 authentication, AuthN
    • 「通信の相手が誰（何）であるかを確認すること」．純粋な「認証」には，「リソース」やそれに対する「権限」という概念は登場しない．
  • 認可 authorization, AuthZ(AuthR)
    • 「とある特定の条件に対して，リソースのアクセス権限を与えること」．純粋な「認可」には，「誰」という考え方はない．

認証と認可の密結合

全く別の概念であるが，古くから認証と認可は密に結合した概念として捕らえられてきた．

  • 認証 -> 認可
    • 相手は admin さんだから，アクセスが許可される．
    • 相手は admin さんではないから，アクセスは許可されない．
  • 認可 -> 認証
    • アクセスが許可されるということは，相手は admin さんだ．
    • アクセスが許可されないということは，相手は admin さんではない．

このように，逆・裏・対偶が全て成り立つことはあまりないかもしれないが，「通信相手の確認」とその通信相手に対する「権限の付与，または決定」がほぼ同義として扱われていた．

「純粋な『認可』には『誰』という考え方はない」と述べたが，それでも多くの場合，認証を前提とした認可が行われ，認可は認証に依存している．

つまり，認可の意味，「とある特定の条件に対して，リソースのアクセス権限を与えること」の「とある特定の条件」というのが，「相手が特定の誰かであることが認証されている」という条件であることが多いのである．

例えば，「サービスに登録済みのユーザかどうかを確認した後（認証），サービスの利用を許可する（認可）」というのが一番単純な例である．

ここまで見てきた通り，「認証と認可の密結合」の事例は多くあるが，あくまでも認証と認可は別の概念であることはサービスを作る側としては意識したい．

認証と認可の分離

Web 技術の発達にともない，本来人間が持つ権限を外部システムに移譲する仕組みが勃興した．これが OAuth である．

例えば，Twitter と Togetter の関係を考えてみる．

Togetter というサービスは，Twitter ユーザ（例えば @nukopy）に成り代わり，（@nukopy という名の下に）Twitter に対してツイートを行う，というリソースの操作を行う．Twitter からしてみれば，通信の相手は Togetter である一方，Togetter が持っている権限は「Twitter に対してツイートの書き込みを行う」という @nukopy のものである．

上記のツイートの例は，「認証と認可の密結合」とは異なり，認証と認可の食い違いがある状態である．Twitter から見ると，

  • 認証（通信の相手は誰か）
    • Togetter（外部システム）
  • 認可（リソースへの権限）
    • ツイートの書き込み

という状態である．本来，Twitter へのツイートの書き込みにおける認証，認可の状態は，

  • 認証
    • Twitter 登録ユーザ（@nukopy）
  • 認可
    • ツイートの書き込み

であるはずだが，この例では Togetter という外部システムに「@nukopy という名の下でのツイートの書き込み」という権限が与えられている．

これは，@nukopy が Togetter に対して「認可の移譲」（特定のリソースへのアクセス権限の移譲）を行った結果である．

Togetter に対して ID とパスワードを渡してしまい，「認証の手段」を丸ごと渡してしまうのわけではなく，@nukopy が持っている「認可」だけを渡している，というのがポイント．

認証 authentication

あらためて，認証とは「通信の相手が誰（何）であるかを確認すること」である．

理解を助ける例えは「証明書の確認」，より具体的には本人確認書類である「免許証の確認」をイメージすると良い．

純粋な認証は，それが完了したからと言って何かが許される話とは関係がない．

例えば，他人に免許証を提示され，そこに「山田太郎」と書いてあった場合，その人を山田太郎さんと認めると思う．だが，それだけである．

（現実では，免許証を提示 -> 会員登録による特定のサービスへのアクセス権限を得るという流れで「認証 -> 認可」が行われることが多い．これも「認証と認可の密結合」と言える．）

認証の 3 要素

コンピュータの世界も含め，現実世界で「認証」を行うための要素には以下の 3 つがある．

1. What You Are(inherence factor)
  • 顔貌（がんぼう），声，指紋，署名など，その人自身を提示して，相手にアイデンティティを確認させる方法．

小さなコミュニティでは，お互いの顔や声を相互に知っているため，面と向かえば相手が誰かは分かり，認証が完了する．

2. What You Have(possession factor)
  • 身分証，携帯電話等，その人だけが持っているものを提示することによって認証する方法．

ある程度コミュニティが大きくなってくると，お互いの特徴を覚えきれなくなるため，そんな場合は身分証明書を提示して，相手を認証する．

また，その身分証には顔写真がプリントしてあることも多く，結果として What You Are に依存するものも少なくない．

3. What You Know(knowledge factor)
  • パスワード，秘密の質問等，その人だけが知っていることを提示して認証する方法．

コンピュータの世界で最も多く使われるファクターである．

認証の 3 要素：まとめ

一般的に，上記 3 つのうちいずれか 1 つを満たすことで認証が完了することが多い．しかし，より確実な認証を行いたい場合は，Multi-Factor Authentication（MFA）という考え方で，複数のファクターを確認することもある．セキュリティの観点から，多くのサービスにおいて MFA の利用が推奨される（ほぼ必須と言っても過言ではない）．

ここまでを振り返ると，API とか リソース とか権限とかは関係ないことが明らかである．「あなたは誰か？」が認証である．

認可 authorization

あらためて，「認可」とは「とある条件に対して，リソースの権限を与えること」である．

理解を助ける例えは「鍵の発行」，「チケット（切符）の発行」である．

  • 純粋な認可は，それがあるからと言って身元が明らかになる話とは関係がない．

また，我々は，誰かから購入済みの切符をもらうことによっても電車に乗ることができる．これは「『電車に乗る』という権限が，切符の購入者から切符を貰った者へ委譲された」と言える．

認可は，それを持っていることによって何か（主に，リソースへのアクセス）が許される．

鍵を持っていれば，（それが誰であろうと）ドアは開くし，持っていなければ開かない．繰り返すが，「権限を持っているのは誰か」は関係ない．

「多くの場合，認可は認証に依存している」と述べたが，これが「認証に基づかない認可」の事例である．

認証と認可の分離に関する疑問

「認証せずに認可する」ことなんてあるのか？

  • ある．切符の例がそれにあたる．切符を買えば「電車」というリソースにアクセス可能になるが，切符が身元の証明になることはない（「切符を買う」という行為は認可を得るための行為ではあるが，決して「認証」ではない）．

その他，iptables の設定で特定の IP アドレスからのリクエストを許可する，というのも認証に基づかない認可である．IP アドレスによって，相手のアイデンティティが確定するとは限らない．

「認証したのに認可しない」ことなんてあるのか？

  • 1 つのシステムに閉じて考えている限りは，まずないと考えて良い．何のために認証したんだ，ということになる．認証を行うシステムにおいては，認証を行う目的があり，多くの場合その目的は「認可を与えるべき相手を選ぶこと」である．

しかし，OpenID Connect 等，認証の委譲が発生するような分散環境においては複雑な事情がありえる．

マクロな視点では「A システムがユーザの認証を行い，その事実を B システムに通知した」という状態において，A システムは「認証をしたが，認可はしていない」ことになる．

  • A システムが認証 -> B システムへ認証されたこと（認証情報）を通知 -> B システムが B システム内のリソースへのアクセスを許可
    • 認証：A システム
    • 認可：B システム

一方，ミクロな視点では「B システムは A システムからユーザを認証したことを通知された．だから B システムは独自で持つリソースへのアクセスを許すことにした．」ということがあるかもしれない（恐らくある）．

しかし，それはミクロの話で，マクロレベルでは A システムは認証しただけであり，認可したかどうかは A システム自身は知らないのである．

例えで考えると，マイナンバーカードを使ってレンタルビデオ店の会員権を得る話．マイナンバーカード自体は何も認可をしていない．しかし，レンタルビデオ店がマイナンバーカードに基いて認可をしている．その状況について，マイナンバーカード発行機関は「知らん」のである．

先ほどの A，B システムと通知の形態は異なるが，全体としてのプロセスは同じである．

  • マイナンバーカード発行機関が個人を認証 -> マイナンバーカード（認証情報）をレンタルビデオ店へ通知 -> レンタルビデオ店がサービス（リソース）へのアクセスを許可
    • 認証：マイナンバーカード発行機関
    • 認可：レンタルビデオ店

マイナンバー発行機関の場合，認証を通知を「人間」が行うため一見違うように見えるが，これは通知の方法が，

  • A システム：メール等
  • マイナンバーカード発行機関：人間

というだけの話であって仕組みは全く同じである．

認証に基づく認可

これが，多くの人が考える認証と認可のパターン．これ以外のパターンをちゃんと認識しないと，世の中の全てがこのパターンのように思えてしまい，「認証と認可」が密結合してしまう．

「認証に基づく認可」の例えは「運転免許証」である．免許証は，写真によりある人が誰であるかを証明し，その上で，その人に対して「『運転という行為』を行う権限」を与えている．

切符のように，誰かに渡しても受け取った人が運転を許されたりはしない．なぜなら，この認可は，「認証に基づいている」からである．

認可に基づく認証（！？）

認証と認可の密結合パターンには以下のようなものもある．

  • この人は山田家の家のドアを開ける鍵を持っているから（認可），山田さんである（認証）．

認証してもらうために，相手に自分の家の鍵を渡すのである．現実ならば鍵を返してもらえば大事には至らないと思いうが，これがコンピュータの世界のトークンであった場合，コピーが相手の手元に残る可能性がある．

この仕組みは、いわゆる「OAuth 認証」と言われるものである．OAuth はあくまでも認可の仕組みであり，認証には関係無い，というのが正式な立場である．

上記のように，実際に認証が成り立ってしまうのは事実だが，

  • 「認証したいだけなのに家の合鍵を渡すってどうなの？」
  • 「そもそも鍵を持ってるからといって，その本人であるとは限らないのでは？」

等々，様々な問題が発生する可能性がある．

非対称な並列比較に注意

以上が認証と認可の切り分けに関する解説．

ここまで比較しておいてアレだが，認証と認可というのは相互に比較するにあたって「対称性」が無いと思われる．

先ほど，認証は証明書，認可は鍵，というメタファを示した．これらのメタファは「発行」と「検証」という段階があると思う．

認証というのは，証明書発行の瞬間ではなく，提示された証明書を検証する瞬間のことを言う．

一方で，認可というのは，鍵発行の瞬間（正確に言えば，アクセスポリシーの定義段階．どのリソースへのアクセスを許可するか）のことを示しており，提示された鍵を検証するタイミング（アクセスポリシー施行段階）を指すわけではない．

OAuth 認証

OAuth2.0 を理解する上でのポイント

Twitter，Facebook，GitHub などのアカウントを用いて別のサービスにサインアップできるのは超便利．これを理解する前に以下のポイントを押さえておくと良い．

OAuth2 は「認証（Authentication）」ではなく，「認可（Authorization）」の仕組み

OAuth2は「ユーザ／パスワードで本人確認」する仕組みではない．正しくは「特定のデータへ特定の操作を許可」するという「認可」の仕組みである．

例えば，GitHub アカウントを使用した OAuth2 であれば，「リポジトリ一覧を読み取り専用でアクセスして OK です．リポジトリの追加はできません．」という操作を他のサービスに許可することが目的である．

この目的のために，結果的に認証も行うため，認証の仕組みとしても広く利用されているというだけである．

OAuth2 の解説は OAuth2 を「利用したいアプリケーションからの目線」で記載されている（ことがほとんど）

OAuth2 を理解するにあたって，重要な登場人物は以下の 3 つ（他にもいくつか中間的な存在の登場人物もある）．

  • リソースサーバ（取得したいデータのあるサーバ）
  • クライアント（データを取得して利用したいアプリケーション）
  • エンドユーザ（取得したいデータの所有者）

ここでの「クライアント」は，「他のアプリケーションに対してアクセスの許可をお願いする立場」である．例えば，Qiita は GitHub アカウントを使用した OAuth2 で認証可能．上記 3 つの登場人物に当てはめると以下の通り．

  • リソースサーバ：GitHub サーバ（ユーザ情報を保持している）
  • クライアント：Qiita というアプリケーション
  • エンドユーザ：Qiita とういアプリケーションにアクセスしているユーザ

ここで許可を与えるという言葉を紐解くと，許可を求めているのはクライアントである．

自分がアプリケーションを作る側（クライアント）だとする．ここでの「許可を求める」とは，

  • 自分のアプリケーションへ登録したいユーザに対して，そのユーザの他サービスでのユーザ情報へのアクセスの「許可」を求める

ということである．他サービスに登録していることが，自分のアプリケーションのユーザになっても良いという信頼の証でもある．ここでは Qiita が GitHub を信頼しているという意味である．

OAuth2 によるアプリケーションのユーザ認証の仕組み

GitHub アカウントで Qiita に登録する際は大きく分けて以下の 3 つの手順を踏む．

  1. 準備
  2. 認証 ~ 認可
  3. 認可後

1. 準備

まず，アプリケーションを実装する段階で，事前準備をしておく必要がある．

0．事前にリソースサーバ（GitHub）からクライアント ID を貰っておく必要がある（ここで，「ユーザ情報を読み取るだけ」などの権限を指定する）．

運用準備

（引用元：OAuth2の解説サイトを漁る前に）

2. 認証 ~ 認可処理

実際に認証 ~ 認可処理を行う．以下の画像の 1 ~ 4 の手順を踏む（画像の番号は，以下に示した手順の番号に対応する）．

認証 ~ 認可処理

（引用元：OAuth2の解説サイトを漁る前に）

※ 本来はリソースサーバ（ユーザ情報など，取得したい情報を持っている別のアプリケーションのサーバ），認可サーバ（アクセストークンを発行するサーバ）は独立して考えるが，ここでは同一サーバで実現する想定で記載する．

1．エンドユーザが自分のアプリケーション（クライアント）にアクセスしてくる．ログイン画面が表示され，エンドユーザが Sign Up with GitHub を押すと，リソースサーバ（GitHub）で認証を行う画面が表示される．

ここでは，ログイン画面はクライアント，認証画面はリソースサーバが提供するものであることに注意．

2．エンドユーザは，リソースサーバにおける認証画面で ID / パスワードを入力する．そうすると，クライアントに対して，エンドユーザの GitHub アカウント情報へのアクセスを許可するかどうかという画面が現れる．許可（Authorize App というボタンであることが多い）を押すと，エンドユーザは「認可コード（リソースサーバから認可が下りたことを表すコード）」を取得する．

これが，エンドユーザが ID / パスワードを入力する一度きりの機会である．ここでは，クライアントを使いたい GitHub ユーザが，クライアントに対して自分の GitHub アカウント情報へアクセスする権限を与えた（認可）．その権限を表すのが「認可コード」である．

3．認可コードを受け取ったエンドユーザは，クライアントに認可コードを渡す．ここで権限の移譲が起こる（ただし，まだリソースサーバへのアクセスは許可されていない）．

4．クライアントが，以下 2 つをリソースサーバ（GitHub）に渡し，「アクセストークン」を取得する．

  • 自分（アプリケーションの管理者）を示す「クライアント ID」
  • エンドユーザから預かった「認可コード」

これで，クライアントは「エンドユーザの代わりに、エンドユーザが所有するリソースに対して限られた操作ができる権利」として，リソースサーバ（GitHub）から発行される「アクセストークン」を取得する．

（ここで完全にリソースサーバのリソースへのアクセスが許可される）

3. 認可後

5．これ以降，クライアントは「アクセストークン」を添えてリソースサーバ（GitHub）にリクエストすることで，欲しいリソースに繰り返しアクセスすることができるようになる（「アクセストークン」はリソースサーバのリソースへのアクセスを許可されていることを示す証拠！）．

ただし，アクセストークンには基本的に有効期限があるため，これに関してはクライアント側で別途管理する必要がある．

認可後

（引用元：OAuth2の解説サイトを漁る前に）

ACL / アクセスコントロールリスト / アクセス制御リスト

  • アクセスコントロール Access Control List

ざっくり言うと，「リソース（ファイル，ディレクトリ，ネットワークなど）へのアクセス権利」

開発環境 / 本番環境 / ステージング環境

開発環境，本番環境，ステージング環境はそれぞれに役割があり，開発の工程に応じて必要になる．

開発環境の役割

  • エンジニアがコーディングしたプログラムの動作確認を行う，開発のための環境．
  • 多くの場合，個人の PC 内に Docker，Vagrant などで立ち上げた仮想環境が使われる．また，クラウド上に動作確認のための共有の PaaS を置くだけという場合もあり，「とにかく動けば良い」というイメージ．
  • 言語やミドルウェアのバージョンを本番環境と合わせておけば，最低限開発環境としての要件を満していると考えられる．

本番環境の役割

  • サービスを一般に公開するなど，実際に運用するための環境（「プロダクション環境」とも）．
  • 要件定義の段階で環境構成案を検討し，その際に冗長化やバックアップの方針など，運用面をしっかり意識して構成を決定する必要がある．
  • オンプレミスであれば，物理サーバなどの機体の購入が必要になるため，クラウドより慎重に行われる（クラウドだから安易に決めるとかではない）．
  • 本番環境は，ただ動作すれば良い訳ではなく（速度面，障害時の対応等も含めて）「『ちゃんと』動作すれば良い」という環境

ステージング環境の役割

  • ステージング環境は日本語で言うと「検証環境」．本番環境の「『ちゃんと』動作すれば良い環境」という部分を「検証」する環境のことである．
  • 「『ちゃんと』動作する」というのを確認するのが「テスト（試験）」．
  • つまり，ステージング環境とは「テストを実施するための環境」である．

では，「テストを実施するために環境に」必要な要件は何か？

ステージング環境の事例：テストを実施するための環境に必要な要件とは？

以下 5 つのプロジェクト事例を紹介．

  • 本番環境相乗り型
  • 可用性排除型
  • （理想）本番環境模倣型
  • 開発用ステージング環境 + 本番維持環境型
  • 開発とステージングの差が名前の差だけならば，ステージングの存在など不要だ！型

本番環境相乗り型

  • 言葉通り，本番環境のサーバにステージングの資材を相乗りさせる．Apache の conf でパスを切って，URL を https://xxx.com/staging/~~ とするとステージング環境に繋がる，というもの．
  • Web サーバだけでなく MySQL や Memcached なども全て相乗り．
  • 普通はありえないが，費用の問題でこういった構成になりうる．
  • しかしテストはできる．本番環境と同じサーバのため，ミドルウェア等が同じバージョンで動作する．
  • これは「検証できている」と言えるのではないか？

可用性排除型

以下のような環境．左が本番環境，右がステージング環境の構成．

可用性排除型

（引用元：プロジェクト2 - 可用性排除型）

  • 可用性の観点から必要なロードバランサー（LB）がステージング環境には設置されていない構成．ステージング環境は常時動くものではないため可用性など必要ない，という観点から構成された環境．
  • LB の設置にも費用がかかる．その費用を削減したリーズナブルな環境．
  • 当然 Web サーバの中身は本番と同等のものを利用．
  • 非機能における負荷試験やスケールの試験は，リリース前に本番環境で行えば良い．
  • 機能試験や外部連携試験を行う環境として構築した「ステージング環境」となっている．

（理想）本番環境模倣型

  • 理想
  • 本番環境と全く同じ構成．
  • LB にぶら下がるサーバの台数はクラウドなので自由に変更可能なため，普段は 2 台のみにして節約を計る．試験状況に応じてスケールアウトをしていく．
  • 本番環境と同じ構成であるため，どのような試験も本番環境と同じであるという信頼性が持てる．
  • しかし費用が嵩む．

開発用ステージング環境 + 本番維持環境型

上記の３つと少し毛色が違う（並列で紹介するのはちょっとナンセンス？）．

登場人物（環境）は，

  • 開発環境
  • 開発用ステージング環境 <- New!!
  • 本番維持環境 <- New!!
  • 本番環境

以下説明．

  • 「開発用ステージング環境」というのが所謂「ステージング環境」のことで，それとは別に「本番維持環境」というものがある．
  • これは、「一度リリースしてお終い」のサービスなら不要だが（そのようなサービスは少ないが），継続的な機能追加などのリリースが必要な場合に必要な構成となる．
  • 「次期リリースに向けてステージング環境の資材を更新し，試験実施の最中」という状況だと，ステージングと本番の動作が当然異なってしまうため，「ステージング環境においては本番で発生した不具合の原因調査を行うことができない」ということを避けるために構築された環境．
    • 開発用ステージング環境：機能追加，ミドルウェアやフレームワークなどのバージョンアップなどのための検証環境．
    • 本番維持環境：本番環境を維持した環境．本番で発生した不具合の原因調査のために本番環境を維持している．
  • 運用面まで加味した「検証」を行うため，「本番維持環境」も広義の「ステージング環境」と言える．
  • しかし，インフラ面では「本番環境模倣型」の 1.5倍 の費用が嵩む．

開発とステージングの差が名前の差だけならば，ステージングの存在など不要だ！型

だめ絶対．

「開発環境で機能試験をすればプログラムとしての動きを担保できているため，改めてステージング環境なんて立てる必要はない，本番環境にリリースあるのみ」という考えの元での構成．

それぞれの型の評価

「機能試験」，「負荷試験」，「リストア試験」，「外部連携試験」など様々な試験の単語出てきた．「試験」と一口に言っても，多くの種類の試験が存在する．これら全ての「試験」を正確にこなせる環境である，というのが「ステージング環境」の要件ではないだろうか．

今まで列挙してきた型を評価してみる．

本番環境相乗り型

ステージング環境としては微妙．

  • これは一見残念な環境だが，ある意味で本番と検証が一致している環境であると言えるため，試験は正確にこなせる気がする．
  • 良くない点
    • しかし，同じ環境であるがゆえにサーバの中に資材を格納するパスが一致しない．外部のファイルを相対パスで参照するようなプログラムがあった場合，本番環境での正当性は疑わしいものになってしまう．
    • また，負荷試験を実施した際，本番稼働前なら良いが，本番稼働後は，ステージングへの負荷が本番環境を圧迫してしまい目も当てらない．

可用性排除型

割と多くのプロジェクトで取られているステージング環境．ステージング環境としては失格．微妙じゃなくて失格．「本番環境相乗り型」より悪い．

  • そもそも本番環境と構成のレベルで異なっているのであれば試験にならない．
    • LB が付与する HTTP ヘッダの情報などがあるが，これをステージング環境で確認できなくなり，「ログにクライアント IP アドレスを出していたが，本番になったら出なくなった」などの珍事が起こりえる．
    • 「セッション情報をファイル出力にしていたため，冗長化したらセッションが切れた」というプロジェクトもある．
    • さらに，この環境も負荷試験を正確に行えない．Web サーバが 1 台しか存在しない場合のスループットしか測定できないため，Web サーバをスケールアウトすることで期待通りに性能が上がって行くのかが計測できないためである．
      • ex) Web サーバを 2 台にした時点で DB がボトルネックとなってしまい，3 台以降増やしても十分な効果を得られない，と言った状況を観測できない．

（理想）本番環境模倣型

環境は非常に理想的．

  • Web サービスである場合，ドメインはステージング用に別途取得することが多いと思うので，そこだけは設定が変わってしまう（クライアントの hosts を書き換えたり DNS を切り替えたりすることで対応も可能だが，どちらが良いかはちょっと判断が難しい）．
  • クラウドであればスケールの試験も容易に行える．
  • ただし，LB の下には最低でも 2 台のサーバは必須．1 台のみだと，結局冗長構成にした時の動作を担保できない（先のセッションの件など）．
  • 構成は似ているが本番は AWS，ステージングは Heroku，みたいなサービスの話を聞いたことがあるがこれは避けるべき．結局構成が違うことには変わりません．また，パブリッククラウドにはそれぞれ特性というか癖もある．

開発用ステージング環境 + 本番維持環境型

「本番環境模倣型 + 本番維持環境」の状況．問い合わせ等が多いサービスであればこの構成が一番望ましいのではないだろうか．

  • 本番環境で障害が発生した際，本番環境のログなどはもちろん参照するが，再現性があるか，どのように修正可能か，と言ったことは本番環境で試すのはナンセンス．
    • それがサービス全体に影響を与える可能性がある．そのため，別件の開発スケジュールにも影響を受けない「本番維持環境」というのは意外と重要になってくるのではないだろうか．
  • 費用は嵩むので注意．

開発とステージングの差が名前の差だけならば，ステージングの存在など不要だ！型

失格．

まとめ

ステージング環境の構成を色々上げてきたが，結局以下の言葉に収まる．

  • ステージング環境は本番環境と同等の構成でなければならない

ただ，そもそものコスト，サーバリソースの面でそのような構成は不可能というのは往々にしてある（特に SIer なら検証環境の大切さを顧客に理解させる必要がある）．

「ステージング環境は本番環境と同等の構成でなければならない」というのは理想論であるため，不可能な場合に現状で取れる最善策は何かというのを考えることが大切である．また，その際に，「検証環境と本番環境のどこが異なることでどのような問題を孕む可能性があるのか」ということを明確に理解しておくことが重要になる．これが分かることで顧客にも環境差異によって担保できなくなる状況を説明できるようになるため，悲劇を未然に防止することができる．

冗長性 / 冗長化

  • バックアップを取る．予備を用意する．予備システムを準備すること．

意味，単語

  • redundancy：冗長性
  • redundant：冗長な
  • 意味：余分なもの，余剰がある，重複している．
    • 一般にはネガティブな意味合いで使われる．

IT の分野では，「余裕のある状態」，「二重化」などポジティブな意味合いで使われることが多い．

コンピュータシステムにおいては，耐障害性を高めるためにネットワークを含むシステム全体を二重化（多重化）し，予備システムを準備することを「冗長化」といい，冗長化によって信頼性，安全性を確保した状態を「冗長性がある」という．

  • ネットワークの冗長化
    • 回線を複数用意すること
  • ストレージの冗長化
    • バックアップを取ったり，パリティを取ったりすること

つまり，障害等に備えて「まわりくどく」何かを用意することである．

（データ圧縮などにおいては，効率性の妨げになる余剰分を排除するという場合に本来の余剰，重複の意味で使われることもある．）

英単語

invoke

  • 意味：（神に）祈る．（精霊を）呼び出す．
  • IT での意味
    • 転じて，（アプリケーションを）起動する．（関数を）呼び出す．
    • ex1) zsh invoked Firefox.：zsh は Firefox を呼び出した．
    • ex2) invoke main function.：main 関数を呼び出す．

verbose

polyfill / ponyfill

JavaScript を書くにあたって，いまだにブラウザによっては存在しない機能を考慮せざるを得ない状況が続いている．そこで取る対策として，polyfill と ponyfill がある．

これらは，「ブラウザごとの実装差」を埋めるための概念である．

polyfill

  • polyfill
    • 標準となったメソッドが存在しない場合に，自分で供給してしまう方法のこと

JavaScript に加わる新機能の中で，文法ごと書き換わってしまうものはどうしようもないが，新しい標準関数が増えた場合，自分でprototype に書き足してしまうことも可能．

なお，「polyfill」という単語は，壁などの「隙間を埋める」ペーストの polyfilla に由来．

  • polyfill のメリット

    • 本体コードを書き換えずに済む．
    • 足りない関数だけ polyfill を実装すれば，残りのコードはそのままで幅広いブラウザに対応できる．

  • polyfill のデメリット

    • 今までできたことをスッキリ書くような，ユーティリティ型のメソッドであれば，今ある機能で，仕様と全く違わぬ動きをさせることができる．一方で，新しく加わったものの場合，完璧に polyfill できないこともある．例えば，WeakMap の「キーがガベージコレクトされたら値も巻き添えになる」という動作は，JavaScript 内で実現することができない．
    • 「正式なメソッドと微妙に異なる polyfill」は，他のライブラリと組み合わせた際に，思わぬバグのもととなる．

ponyfill

そこで，「Polyfill」という単語を少し書き換えた「Ponyfill」という概念が登場する．これは，「polyfill が暴れん坊なのに対して，ポニーのようにピュアなもの」を意図している．

実装自体は polyfill と同様に自前の JavaScript を用意はするが，それを標準オブジェクトに上書きするのではなく，全く別個の関数として使えるような形で実装しておく，というような手法．

polyfill に関する現実

実際の polyfill ライブラリを見てみると，存在しないブラウザにコードを追加するコードどころか，「既存の実装のバグをチェックし，バグが存在する場合には自前コードに切り替える」ものすら存在している（闇が深い）．

revolves around

  • 意味：〜を中心に回る．〜を中心に展開される．
    • ex) Redux architecture revolves around a strict unidirectional data flow.：Redux アーキテクチャは，厳密な単方向データフローを中心に展開される．

略語，頭字語

IT の文脈で出てくる，略語（abbreviation），頭字語（acronym）のまとめ．

略語 abbreviation

頭字語 acronym

WYSIWYG

コンピュータのユーザインターフェースに関する用語で，ディスプレイに現れる内容と処理内容（特に印刷結果）が一致するように表現する技術．

"What You See Is What You Get"（直訳で「あなたが見るものはあなたが得るもの」）の頭文字を取った単語．「ウィジウィグ」と発音する．is を外した

最も分かりやすい例は，Microsoft Word（所謂 Word）と LaTeX による文書作成である（参考：どうしてLaTeXを使うのか、もう一度考えてみる）．

Word では自分が編集している文書の見た目が（多少のずれはあれど）印刷結果と一致する．つまり，Word は WYSIWYG 方式の文書作成である．

一方，LaTeX は編集している文書（ソースコード）と印刷結果は一致しない．

LGTM

"Looks Good To Me" の略で，「私にはそれは良さそうに見える（思える）」を表す頭字語である．Pull Request などで「これは良さそうだね」という気持ちを表す語としてしばしば用いられる．

Previous
GitHub
Next
Platforms
© 2019 nukopy All Rights Reserved.