nekonoteも借りたい

nekonote が IT系の技術を学んだ際のメモなどを残していこうと思います

RESTにおける「コードオンデマンド」の可視性の低下のデメリットとは?

こんにちは、nekonote-civ です(ΦωΦ)

本日は先日のRESTについて勉強する - RESTとは? - nekonoteも借りたいに記載した「コードオンデマンド」と「可視性」について調査した内容をまとめてみようと思います!

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus) | 山本 陽平 |本 | 通販 | Amazon

目次

本記事をまとめようと思った経緯

フィヨルドブートキャンプ では日報を書くのですが、いつものように書籍を読み「ここが大事だな!」と思ったところを書き連ねていたところ、「コードオンデマンドにより可視性が低下する」という自分で書いた文章の意味を説明出来ない事にふと気づきました。

引用元:Webを支える技術 P.90 付近

ただし、コードオンデマンドには欠点もあります。それは、ネットワーク通信におけるプロトコルの可視性が低下することです。 HTTP というアプリケーションプロトコルに従って通信している間は、通信の意味やアクセスするリソースが明白です。しかしコードオンデマンドでプログラムをダウンロードし、クライアント側で実行してしまうと、アプリケーションプロトコルの可視性は低下します。

「可視性が低下すると何が駄目なの?」と問われたらどう答えるべきでしょうか?

どうしても自分で答えが見いだせず、フィヨルドブートキャンプ 内のQ&Aに投稿したところ、「原典である論文を読もう」という非常に的確なアドバイスを頂き、調査をしたのがこの記事の内容になります。

論文を読もう(可視性について)

以下の内容は、ロイ・フィールディングという、コンピュータ学者でありRESTの創始者の方の論文から引用しています。

www.ics.uci.edu

該当する用語を見ていくと、2.3.5 Visibility がまさにマッチングする内容と見られるため、こちらに注目してみます。

Styles can also influence the visibility of interactions within a network-based application by restricting interfaces via generality or providing access to monitoring.

ここでのスタイルは、クライアント/サーバ間のインターフェースを制限(GET/POST等)したり、モニタリングを提供することで、ネットワーク上でアクセスするアプリケーション内の相互作用の可視性に影響を与えることが出来る、と説明していると読み取れます。

Visibility in this case refers to the ability of a component to monitor or mediate the interaction between two other components.

この場合での「可視性」とは、コンポーネント間(ここではクライアント/サーバと考える)の相互作用を監視/仲介するコンポーネントの能力を指しているのでは無いでしょうか。
コンポーネントという言葉は「部品」といった意味合いが大きそうですが、「監視するコンポーネント」となると監視サーバとかが考えられそうですね。

Visibility can enable improved performance via shared caching of interactions, scalability through layered services, reliability through reflective monitoring, and security by allowing the interactions to be inspected by mediators (e.g., network firewalls).

可視性は、インタラクションの共有キャッシングによるパフォーマンスの向上、階層化されたサービスによるスケーラビリティ、リフレクション モニタリングによる信頼性、およびメディエータ (ネットワーク ファイアウォールなど) によるインタラクションの検査を可能にすることによるセキュリティの向上を可能にする。
...ちょっと難しい横文字が多くて大変ですが、「そもそも可視性が高いと、パフォーマンスの向上やセキュリティリスクの軽減を期待できる」みたいな感じでしょうか。

The mobile agent style is an example where the lack of visibility may lead to security concerns.

モバイルエージェントのスタイルは、可視性の欠如がセキュリティの懸念につながる可能性がある例である。

ここでのモバイルエージェントとは「ネットワークを介した分散処理技術により、ネットワーク接続されたコンピュータ間をエージェントと称されるプログラムが移動しながら処理を行うもの」といったもの。
同書に当てはめると「JavaScript」「Javaアプレット」など、クライアント側にプログラムをダウンロードして処理してもらうという部分のことを指している事が分かります(前回の記事で出てきた「コードオンデマンド」のことですね)。

「モバイルエージェント」については下記のような論文も出ています。

モバイルエージェント技術と研究動向

論文を読もう(コードオンデマンドについて)

先程の論文の3.5.3 Code on Demand (COD)でコードオンデマンドについて説明されています。

The advantages of code-on-demand include the ability to add features to a deployed client, which provides for improved extensibility and configurability, and better user-perceived performance and efficiency when the code can adapt its actions to the client's environment and interact with the user locally rather than through remote interactions.
Simplicity is reduced due to the need to manage the evaluation environment, but that may be compensated in some cases as a result of simplifying the client's static functionality.
Scalability of the server is improved, since it can off-load work to the client that would otherwise have consumed its resources. Like remote evaluation, the most significant limitation is the lack of visibility due to the server sending code instead of simple data.
Lack of visibility leads to obvious deployment problems if the client cannot trust the servers.

こちらも要約すると

「コードオンデマンドはクライアントに機能を追加することで拡張性が高く、ローカルで実行するためサーバリソースを消費せずスケーラビリティが向上する。
しかし、サーバーがデータのやり取りではなく「コード」を送信するため、可視性が欠如する。 また、これは「クライアントがサーバを信頼するという」前提の元で成り立っている」

といった感じでしょうか。 「データ」ではなく「コード」を送る、というのがここの肝となります。
外部から確認できるデータ(通常はHTMLやTEXTの形式)ではなく、プログラムコードがサーバ/クライアント間を流れていると、それを見ても「何をしているかわからない」状態になってしまうようです。

ここまでを元にした自分の解釈

ここまでの内容や論文内の「Visibiliry」に関連しそうな箇所の内容をまとめてみると、

RESTというアーキテクチャスタイルを利用することにより、固定のメソッドや形式(インタフェース)にて通信が行われるので必要以外なところを気にせずに決まったルールで監視も出来るし、セキュリティ性の向上が期待できたり、階層化することでスケーラビリティを持つことなどが出来る。

といったことが可視性を持つ事による主なメリットになるのではないでしょうか。

そして、可視性というのは「クライアント/サーバ」間での相互作用を監視/仲介してくれるコンポーネント...つまりここでは主に第3者による REST API の監視などを指すのではないかと考えました。

例えば、Amazon CloudWatch を利用することで REST APIの実行をモニタリングし様々な計測が出来るかと思いますが、これがここでの「可視性」にあたるものの一つではないでしょうか。 このようなモニタリングの仕組みを用いれば、通信の記録を的確に把握して必要に応じた形式に変換し、レポートとして出すことが出来る、アラート管理が容易であるなどのメリットが考えられます。

Amazon CloudWatch のメトリクスを使用した REST API の実行のモニタリング docs.aws.amazon.com

まとめ

特定のインタフェースを用いた通信をしている間は、便利な監視ツール等を用いることで常に安全/拡張性等のある状態を保つことが出来るけど、モバイルエージェントなどを使ってクライアント側で複雑な処理をしてしまう場合、リッチな動作は提供できるが、本来 クライアント/サーバ による通信で常に見えていた細かい作業までもが隠蔽されてしまう事により、上述のようなメリットを受けられない状態を作ってしまう」というのが「可視性の低下によるデメリット」である、と考えました。
(流石にこの概念は一言ではまとまらないですね...)

翻訳ミスによる解釈違い、理解の抜け漏れなども中にはあるかとは思いますが、「可視性が低下すると何が駄目なの?」という疑問に対してはある程度の回答が出来る様になったかと思います。

また、そもそもとして「クライアント/サーバ」間でやり取りしているデータはどのように使われるのか?ということまで意識できていませんでした。
「誰が」「どのように」使用するかを意識できていれば、もう少しメリット/デメリットについては自身でも思いついたのかなと感じます。
広い視野を持って問題を見つめる、というのは今後の勉強でも意識していきたいですね。

あとがき

1月8日から学習を開始しそろそろ3ヶ月目になります!時が経つのは早いですね!
気温も上がってきているので、勉強の合間の散歩がとても気持ちいいです🏃‍♂️

次回の記事は悩んでいますが「Ruby」「Rails」「Git」あたりについてまとめたいなと思っています!

RESTについて勉強する - RESTとは?

こんにちは、nekonote-civ です(ΦωΦ)

現在フィヨルドブートキャンプで勉強している内容にRESTという概念が登場してきました。
こちらもWebシステムについて学ぶ際に非常に重要だということで、主に下記の書籍を参考にしながら整理していきたいと思います。

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus) | 山本 陽平 |本 | 通販 | Amazon

目次

アーキテクチャスタイルとは?

「Webを支える技術」の中ではRESTのことを「Webのアーキテクチャスタイル」と表現していました。
では「アーキテクチャスタイル」ってなんぞや?ということで掘り下げてみると、以下のような記述がそれぞれ確認できました。

[Webを支える技術]

アーキテクチャスタイルは別名「(マクロ)アーキテクチャパターン」とも言い、複数のアーキテクチャに共通する性質、様式、作法あるいは流儀を指す言葉です。 アーキテクチャスタイル には、たとえばMVC(Model-View-Controller)やパイプ&フィルタ(Pipe and Filter)、イベント システム(Event System)などがあります。

アプリケーション概要を定義するには?(3/3) - @IT - ITmedia

アーキテクチャ・スタイルとは、前回でも述べたとおり、複数のアーキテクチャに共通して見られる設計原則の集合のことである。

アーキテクチャ スタイル - Azure Application Architecture Guide

"アーキテクチャ スタイル" とは、特定の性質を持つアーキテクチャのグループです。

上記から、「アーキテクチャスタイル」=「複数のアーキテクチャに共通している性質や様式をまとめた設計における要件(スタイル)の集まり」のようなものであると分かります。
(アーキテクチャ = 構造、骨組み)

色々なシステム構造がある中で、「この構造で動作する仕組みは色々な所で使えるな!」とパターン化しておくことで、アーキテクチャの設計段階における車輪の再発明を防ぎ、効率的で安全なシステムが作れる、という感じでしょうか。

リソースとは?

もう一つ、同書には「リソース」が重要な概念の一つである、とも記述されています。
リソース(Resource)は直訳すると「資源」ですが、ことRESTにおいてはWeb世界における仕組みのことですから、資源ではちょっと意味が分かりづらいです。

こちらについてはMDNの下記が個人的に分かりやすかったです。

ウェブ上のリソースの識別 - HTTP - MDN Web Docs

HTTP 要求の対象は「リソース」と呼ばれ、その本質は細かく定義されていません。ドキュメント、写真、その他の何にでもなりえます。 それぞれのリソースは、リソースを特定するために HTTP の至るところで使用される Uniform Resource Identifier (URI) で特定されます。

「Webの世界でHTTP等により要求される対象は大体リソース」であり、また「URIで特定される」のですから、「一意の名前がついている」という前提が必要です。
(URIについては別途まとめる予定です)

ということで、ドキュメント(HTML, txt等)、写真(jpg, png等)などによらず、一意の名前を持ったWeb上にあるあらゆる情報がリソースであると言えるかと思います。

RESTとは?

では、改めて本題である「REST」について見ていきます。

RESTとは「Representational State Transfer」の略であり、WebAPIの定義に使用されるアーキテクチャスタイルとのことです。
アーキテクチャスタイルという概念がどんなものかは何となく分かってきましたが、RESTは一体どのような設計の性質があるのでしょうか。
こちらも同書に記載の主な項目を見ながら考えてみます。

クライアント/サーバ

Webの世界では、主にサービスを利用する側のクライアント(ブラウザ側)がネットワークを介してサーバに対して通信していますが、これを「クライアント/サーバ」と呼びます。
「クライアントサーバ」「クライアントサーバモデル」などとも呼ばれているようです。

サーバは常にクライアントからの要求を待ち、そのリクエストに応じて処理を行う、という構造です。
これは至ってシンプルであり、クライアントとサーバが分離して処理出来るため、サーバはサーバ側の処理だけに気を使えば良いことになります。
「関心分離の法則」に近い感じでしょうか。

ステートレスサーバ

ステートレス(Stateless)とは「状態(state)を持たない」ことであり、サーバ側がクライアントの状態を管理しないことを指します。
そもそも「状態を管理する」とは何でしょうか?

例えば、Cookieを使ったセッション管理が例に挙げられます。
Cookieはサーバがブラウザに状態を管理するための識別子を渡し、それを使ってブラウザがサーバにアクセスすることで、まるで「サーバがそのユーザを記憶している」ような形でログイン機能などを提供することが出来ますね。

ではステートレスはどうなっているかというと、これらのような状態を一切持たないことにより、一度のリクエストの処理が終わった時点でサーバの作業は終了し、すぐに計算リソースを開放します。
「さっきの〇〇さんからの要求だな」というようなことは判断せず、それぞれ毎のリクエストを新規の来訪者として取り扱い、終わったらその人のことはさっぱり忘れるということですね。

とはいえ制約に反するからとセッションとか絶対利用しない!というのは困る時もあるので、そこはメリット・デメリットを理解して設計することになります。

キャッシュ

キャッシュは、同じ情報などを取り扱う場合に既に持っている情報を用いて不要なやり取りを防ぐ仕組みです。
これにより、ユーザの待ち時間を軽減したり、当然不要な処理をしませんからパフォーマンスも上がります。

また、Roy Thomas Fielding の論文を見る限り、ここでのキャッシュは「クライアント側で保持するキャッシュ」を指していると思います。 www.ics.uci.edu

その為、古いキャッシュを参照してしまうことにより、古い情報を取得してしまう、というデメリットは考えられそうです。

統一インタフェース

統一インタフェースとは、決められた原則に従うように限定されたインタフェースであり、定義された仕組み以外を利用しないようにします。
例えばHTTPには「GET」「POST」などのメソッドが9個ほど定義されており、これ以外は利用できません。

ここを統一することにより、下記のメリットが享受できることになります。

  • サーバ
    定義通りに設計することで、その定義を利用した全ての利用者に正しくレスポンスを返すことが出来る。

  • クライアント
    定義に合わせてリクエストすることで、どのアプリケーションを利用していても、どのサーバ宛であっても定義に則ったレスポンスを受け取れる。

規格が乱立していたらどう要求したら良いかも分からないし、受け取る側もどのような要求が来るかわからないから準備できないわけですね。

階層化システム

クライアントとサーバの間にロードバランサーやプロキシサーバなどを挟むことにより、負荷分散を行ったりアクセス制限ができたりします。

[クライアント] <--------> [プロキシサーバ] <--------> [サーバ]

また、HTTPが利用できないようなレガシーなシステムとクライアントの間にHTTPを利用できるサーバを挟むことにより、クライアント側は他のサーバと同じようにRESTを用いた通信を行うことが出来ます。

[クライアント] <--------> [HTTPが出来るサーバ] <--------> [古いサーバ]

このような階層構造を用いることが出来るのも、「統一インタフェース」を採用していて常に要求の形式が決まっているおかげということです。

コードオンデマンド

「オンデマンド(On Demand)」とは、要求があったらその要求に応じたコンテンツなどを提供することを指します。
VOD(Video On Demand)が良い例ですが、これはユーザが見たい時に要求すればいつでも動画を見ることが出来る仕組みですよね。

ではコードオンデマンドはどういうものかというと、プログラムコードをサーバからダウンロードしてクライアント側で実行する仕組みを指します。
JavaScript」「Flash」「Java アプレット」あたりがそういう仕組みのようです。

これによりリッチなWebサービスを提供することが出来ますが、サーバからはデータではなくプログラムコードが送られる為、それを外部から監視/分析することが難しい、つまり可視性が低下してしまうようです。

ちょっとここの「可視性が低下する」とどのようなデメリットがあるのか記事を書き始めた時にピンとこなかった為、フィヨルドブートキャンプ内で質問をしつつ自分の考えをまとめてみました。
ちょっと長くなってしまうのでこちらについては次回の記事で公開します!

まとめ

ここまでをまとめると、上述のような様々な性質を持ったものが「REST」の根本的な部分でありますが、これを全て適用しないとRESTではない、というわけでもなさそうです。
ステートレスの時に出したセッションの話がまさにそれですね。
それぞれの内容を上手く組み合わせて、システムに落とし込むのが設計者の技術の見せ所なのかなと思います。

正直書いていて「階層化システム」とか「統一インタフェース」のあたりがふわっとしたので、ここはもう少し掘り下げて理解出来るようにしたいですね。

次回は「RESTにおける「コードオンデマンド」の可視性の低下のデメリットとは?」という素朴な疑問から始まったRESTにおける可視性について調査した内容を書いていきます!

WSL2でOSの手動インストール(Debian)

WSL2でOSの手動インストール(Debian)

こんにちは、nekonote-civ です(ΦωΦ)

WSL2を利用する中で、現在の環境を壊さずに新しく同じOSを入れたいという事、ありませんか?
通常、何かどうしようもない問題が発生した際にはクリーンな環境にするものかと思いますが、私は現在学習中であり、更に課題をこなしている最中なのでまっさらになるのは少し困ってしまいます。

そこで、WSL2の手動インストール機能を使ってOSを増やすことにしました。
私はDebianを使っていますが、同じようなことが他のOSでも出来ると思いますので、もしもの場合は試してみてください。

ちなみに通常のリセットはこちらのサイト等で記載のある通り簡単に出来ます。 atmarkit.itmedia.co.jp

また、本サイトの内容はMicrosoftの公式サイトにほぼ記載があるものですので、公式ドキュメントさえあれば良いという人は下記を参照してください。
learn.microsoft.com

目次

ディストリビューションのダウンロード

まず、インストールするためにはディストリビューションの本体が必要になります。
こちらから自分のインストールしたいOSのディストリビューションのリンクをクリックしてダウンロードしてください。
私は今回Debianを使用しているので赤枠のところですね。

ダウンロードは自動で始まりますので少々待ちましょう(OSによってはサイズが大きいかも)。

ダウンロードしたファイルの展開

ダウンロードが完了するとこのようなファイルがダウンロード出来たかと思います。
「AppxBundle」という見慣れない拡張子ですね。

ダウンロードが完了したらこちらのファイルの拡張子を「zip」へ変更します。

拡張子が変更できたら7-zipなど何でも良いので展開しましょう。
展開するとフォルダが出来ると思いますので、その中を確認すると下記のような構成になっていると思います。

更にこの中にある「DistroLauncher-Appx_1.12.2.0_x64.appx」を同じ様に「zip」へ変更し、展開します。
これでダウンロードと展開の作業はOKです!

WSL2でインポート

さて、それでは展開したファイルを使ってインポートしていきたいのですが、恐らくダウンロードしたままのディレクトリで作業されている方もいるのでは無いでしょうか?

ダウンロードフォルダはキレイにしたい時などもあると思いますし、今後他のディストリビューションを使うことも考えて私は下記のようなフォルダを作って移動しています。
この時移動するファイルは「install.tar.gz」だけで大丈夫です!(これしか使わないので)

さて、準備が出来たらWSL2のコマンドを使ってインポートしていきます。
いきなりやる前に最初にコマンドの確認をしておきましょう。
下記がインポートするためのコマンドです。

wsl --import <DistroName> <InstallLocation> <InstallTarFile>

これだけだと分かりづらいので、私の環境で当てはめてみましょう。

wsl --import Debian-Test C:\wsl\packeges\Debian-Test C:\wsl\exports\Debian\install.tar.gz

まずwsl --importはインポートするためのコマンドですね。--importとハイフンが2つなので注意です。
Debian-Testですが、こちらは自分が今後使うこのディストリビューションの名前なので分かりやすいものを付けましょう。
C:\wsl\packeges\Debian-Testはインポートした仮想マシンが展開されるフォルダです。

下記は実際に私が使っている2つ目のDebianちゃんですが、「.vhdx」という仮想ハードディスクが展開されるのが分かります。

最後のC:\wsl\exports\Debian\install.tar.gzは先程移動したインポート用のファイルですね。

さて、ファイル名や新しい仮想マシンの名前に問題なければコマンドプロンプトを開いて実行しましょう!

実行するとこの様な表示が出ますので少し待ちましょう。

私の環境では数秒で完了し、このようになりました。

Debianを起動

インポートした後は起動する必要があります。

まずはWSL2の状態を確認していきましょう。
下記のコマンドでインポートされているディストリビューションなどが確認できます。
赤字のように先程自分が決めた名前のディストリビューションがあればOKです。

さて、先程ステータスが「Stopped」になっていましたので、起動する必要がありますね。
wsl -d <DistributionName> が起動コマンドです。
今回の場合はwsl -d Debian-Testになりますね。

では早速起動してみましょう。

下記のように起動してログイン出来ればOKです! お疲れ様でした!

参考にしたサイト

公式サイト以外に下記のサイトを参考にさせていただきました!

https://pcvogel.sarakura.net/2020/08/30/32064

http://www.y2sunlight.com/ground/doku.php?id=wsl2:ubuntu