Published
- 11 min read
OSI参照モデルって、7階層以外にもいくつかあるよねってお話
Classiアドベントカレンダー23日目です。
本日はエンジニアの大半が嫌いな政治が絡むお話です（汗
前提として、OSI参照モデルの7階層を知っている人を対象としています。
1.はじめに
アドベントカレンダーを書く際、「今年、どんなことしてたかなあ？」と社内Slackなどを遡ってみたら、「OSI参照モデル7階層より上の動きをする人っているよねー」って話があがってました。
ちょっと調べたら、海外でも比喩に使われることがあるみたいで、L7以上だけでなく、L0含めてこれまで経験した内容をメモ程度に書いておこうかなと思ったのがきっかけです。
OSI参照モデルの図 IPAのサイトより
Flickrに投稿された、ISCのTシャツ画像より
L7層以上はユーザー層とかでまとめられるレイヤーとも記載されているところはありますが、ユーザー層に踏み込むとセキュリティとかの広い話に踏み込んでいるところもあるので、本投稿ではInternet Systems ConsortiumのTシャツの画像に記載されている
- L8レイヤー（財務層）
- L9レイヤー（政治層）
と定義して、記載してみます。
2.参考サイト
国内
OSI参照モデル – アンサイクロペディア 【インタビュー】レイヤ8セキュリティとは－コミュニケーションを活性化するセキュリティ機器「Vario Communicate Router」 OSI 12階層モデル 仕事をするうえで意識したい、OSI参照モデルのプラスアルファ
海外
3.L8レイヤー（財務層）
どんなレイヤー？
- オンプレの場合
各種機材購入費用、機材設置費用、減価償却費用、回線使用料、ラック使用料など - パブリッククラウドの場合
サービス利用料 - システム開発の場合
業務委託費用、ソフトウェアライセンス費用など あたりがここのレイヤーに絡んでくると思われます。
どんなプロトコルで疎通を行う？
お金です。
RI購入や複数の機材調達などは大きな動きが発生するので、会社によっては取締役会などでの説明が求められることがあります。
特に、AWSを使っていると、RIを購入するときにはかなり巨額の金額が動くので、現場だけで購入時期を決定することはできず、会社の決算時期やプレスリリースの発表などを考慮することも必要になってきます。
余談ですが、AWSの場合、RI購入やエンタープライズサポート費用など巨額の金額が動く際に、膨大な資料提出と説明が求められることも考えられます。
そのような事態を避けるため、現場だけでなく経営側にもサーバー費用の用途などを説明しておくことは、エンジニアリングに専念できる環境を作るという観点でも必要なことかなと（若干、L9レイヤーにも関わるがなという独立性のなさはいったん無視でw）
4.L9レイヤー（政治層）
どんなレイヤー？
L8レイヤーで発生した費用に対するサンクコストとか、所属グループで決めたパブリッククラウドの運用方針とか。公共系が絡む業界だと、各省庁が出しているガイドラインとか条例とか。ビジネスによっては、プライバシーマークやISMSなどの第３者認証を取得しなければならないとかもあるので、ここのレイヤーに含めてもよいのかなと。
どんなプロトコルで疎通を行う？
信頼関係です。半分ネタで半分事実ですw 平成も終わりに差し掛かっていますが、技術が進歩した現代であっても、要件によっては、対応しきれないパブリッククラウドとかもあったりします。そういった場合、代替案となるサービスや運用方針を探すことになるのですが、最終的に運用者を中心としたステークホルダーとなる方々が対象システムの運用に対して合意できるかという観点が必要になってきます。
このあたりのステークホルダーを説得する方法としては、アリストテレスの弁論術にも記載されている「ロゴス」「エトス」「パトス」の概念で説明できると考えていたのですが、メルカリさんのBIチームでは採用時のフレームワークでも使われている1ということをお聞きし、流石だなあと思います。
ステークホルダーが多くなってくると、技術的なロジックだけでは納得してもらえなかったり、説明者が何層か挟まり、自分が説明する場がなかったり、人によって見解が分かれたりするので、システム環境の整備だけでなくコミュニケーションまわりの環境整備というのも組織においては重要なお仕事になります。
5.L0レイヤー（土建層）
最初、OSI参照モデル7階層より上の話だけで終わろうかなと考えていたのですが、システムのインフラを考えるときに、今年はL1よりも下のL0レイヤーにも触れることも多かったので、補足しておこうかなと。
どんなレイヤー？
L1で各サーバーをつなぐハブなどを定義していますが、その機器を設置するデータセンター選定などが必要になることがあります。データセンターのサービスレベルは、日本データセンター協会が定義しているファシリティスタンダードがあるので、そちらを参考にしていただければと。
参考
データセンター／クラウドサービス選びの「基礎知識」と「重要な観点」（前編：データセンター編）
どんなプロトコルで疎通を行う？
システムの非機能要件です。
L0レイヤーだけで会話することはできなくて、実現したいシステムやビジネスのサービス品質に応じて、可用性やセキュリティを担保することになります。
AWSのようなパブリッククラウドを使うと、リージョンとかアベイラビリティゾーンとかがデフォルトでついてくるので、パブリッククラウドを単純に使うだけだとあまり意識することがなくなってきました。
ただ、東日本大震災や、今年生じたデータセンター火災のようなことがあったときに、サービスのデータを守るときの意識として、このあたりの意識もしておくとより安心できるサービス設計ができるのではないかなと思います。
(筆者経験談なのですが、東日本大震災のとき、当時所属していたインフラチームの同僚が、東北にあるデータセンターで作業しており、「作業対象のサーバーラックにアンカーが打ち込まれていなければ、結構怖いことになっていたかもな」と、当時の上長と話していました)
パブリッククラウドが主流になってきた現在であっても、いざパブリッククラウドが使えない案件が振ってきたときに、どのようなデータセンターでどのような運用をされているかを認識しておけば、何がビジネス上のリスクになり得るかを見つけやすくなるかなと。
6.さいごに
自社サービスで運用していても、システム開発はたくさんの人が絡むので、こうしたOSI参照モデル7層以外も意識することが必要なときはくるかなあと。8層より上の動きは各社違うことが多いですが、システムの非機能要件を整理するときにも必要な内容なので、意識をしておくと何かしら役に立つことはあるかなあと思います。
このような動きは結構嫌う人も多いのですが、この辺の動きをされている方の何かしらの参考になれば…