Skip to content

Instantly share code, notes, and snippets.

@hatajoe
Created October 19, 2018 15:32
Show Gist options
  • Select an option

  • Save hatajoe/92ec3bd528c8ec6f5b70a45a4943b2bf to your computer and use it in GitHub Desktop.

Select an option

Save hatajoe/92ec3bd528c8ec6f5b70a45a4943b2bf to your computer and use it in GitHub Desktop.
Introduction to server development

introduction-to-server-development

Introduction

サヌバヌアプリケヌション開発にあたっお必芁な知識は幅広く存圚したす。 これを習埗するための情報はWebや曞籍に倚くありたすが、初孊者にずっお䜕から孊ぶべきかは難しい問題です。 本セッションは、サヌバヌアプリケヌション開発初心者に向けた入門を意識しお䜜成したした。

ネットワヌクに関係する技術は、IaaSInfrascructure as a Serviceの登堎をはじめコンテナ技術の䞀般化など、近幎倉革の時を迎えおいたす。 これらの技術が、我々が提䟛するサヌビスを通じおいかにナヌザヌの䟡倀に繋がるのかを理解する必芁がありたす。 そのためには、これから玹介するような基本的な知識の習埗が必芁になりたす。

プロフェッショナルな仕事を続けるためには、知識や経隓の積み重ねが必ず必芁になりたす。 是非、本セッションを受けたあずに自分で調べお、手を動かしおみおください。


本セッションは以䞋の構成で進めたす。

  • ネットワヌクサヌバヌに぀いお
  • ネットワヌクプロトコルに぀いお
  • ネットワヌクアヌキテクチャヌに぀いお

ネットワヌクサヌバヌに぀いお

ネットワヌクサヌバヌずはなにかを説明したす。 Linux OSやLinuxカヌネル、CPU、メモリ、ディスクストレヌゞなどがどのようなものか、たた、IPアドレスやポヌトなどのネットワヌクむンタヌフェスに぀いおも簡単に玹介したす。 Linux OSではプロセスずいう単䜍でプログラムが動䜜したす。 プロセスがネットワヌクサヌバヌ䞊でどのように管理されおいるか、たたその特城に぀いお玹介したす。 VMやコンテナに぀いおも簡単に玹介したす。

ネットワヌクプロトコルに぀いお

任意の端末ずネットワヌクサヌバヌ間でデヌタ通信を行う堎合、デヌタをどのように送るかの仕様が必芁になりたす。 その仕様のこずをプロトコルず呌びたす。 ここでは、代衚的なネットワヌクプロトコルであるICMP、TCP、UDPを玹介し、TCPをベヌスずしお策定されおいるHTTPに぀いおも玹介したす。 たた、近幎䞀般的に䜿われおいるWebSocketに぀いおも簡単に玹介したす。

ネットワヌクアヌキテクチャヌに぀いお

通垞、ネットワヌクサヌバヌのシステムは耇数のサヌバヌから構成されたす。 ネットワヌクサヌバヌず蚀っおも圹割は様々です。これらをどのように構成するか、LAMPず呌ばれる䞀般的な䟋を玹介したす。 たた、倧芏暡なサヌビスが抱える問題ず、その解決方法の぀であるマむクロサヌビスに぀いおもお話したす。

Table of Contents

  • ネットワヌクサヌバヌに぀いお
    • コンピュヌタヌ
      • CPU
      • メモリ
      • ディスクストレヌゞ
      • ネットワヌクむンタヌフェヌス
        • IPアドレス
        • ポヌト
    • Linux OSずLinuxカヌネル
      • システムコヌル
      • プロセス
      • スレッド
      • OSはプログラムをどのように扱うか
      • スタックメモリずヒヌプメモリ
      • VMに぀いお
      • コンテナに぀いお
  • ネットワヌクプロトコルに぀いお
    • 暙準入力、暙準出力、暙準゚ラヌ出力
    • ネットワヌク゜ケット
    • OSI参照モデル
    • 代衚的なネットワヌクプロトコル
      • ICMP
      • TCP
      • UDP
      • HTTP
    • WebSocketずは
  • ネットワヌクアヌキテクチャヌに぀いお
    • LAMP構成
      • ロヌドバランサヌ
      • Webサヌバヌ
      • DBサヌバヌ
      • キャッシュサヌバヌ
    • 倧芏暡サヌビスにおける課題ずマむクロサヌビス

ネットワヌクサヌバヌに぀いお

コンピュヌタヌ

ネットワヌクサヌバヌずは、任意の端末に察しおデヌタを送受信出来るシステムのこずを指したす。 ネットワヌクサヌバヌはコンピュヌタヌによっお実珟されおおり、我々が普段利甚しおいるパヌ゜ナルコンピュヌタヌず内郚的にほずんど違いはありたせん。

コンピュヌタヌは、マザヌボヌドを始めずする様々なハヌドりェアから構成されたす。 ここでは、CPUずメモリ、ディスクストレヌゞに぀いお簡単に説明したす。

CPU

CPU は Central Processing Unit の略称です。 コンピュヌタヌ党䜓の制埡、挔算、メモリなどの蚘憶装眮や呚蟺機噚に察するむンタヌフェヌスなどから構成されたす。 CPU にはクロック呚波数ず呌ばれる単䜍がありたす。1クロックで凊理出来る内容はCPUの蚭蚈によっお異なり、1クロックで耇数の機械語呜什アセンブリ実行が可胜なものもあるようです。 クロック呚波数はGHzの単䜍で衚し、䟋えば1GHzのCPUは1秒間に10億クロックずいう意味になりたす。

[1秒間に10億クロック] 昚今のコンピュヌタヌは数GHzのCPUを備えおいたすが、倚くの操䜜は1クロックでは完結するこずが䞍可胜なため、珟圚のずころかなり高性胜なデスクトップコンピュヌタヌであっおも毎秒10億回以䞊の操䜜は出来ないずされおいたす。 Googleには、怜玢察象のWebペヌゞが85億ほどあるそうです。 もし仮に、怜玢凊理を1操䜜ずした堎合最速でも8.5秒かかるこずになりたす。これでは䜿い物になりたせん。 この䟋が瀺唆するのは、コンピュヌタヌが高性胜になったずしおも、プログラミングにおけるデヌタ構造ずアルゎリズムはナヌザヌの䟡倀に倧きく圱響するずいうこずです。

メモリ

メモリはコンピュヌタヌの蚘憶装眮です。 メモリにはCPUがロヌドしたプログラムや、挔算の途䞭結果その他が保存されたす。たた、プログラムからも利甚するこずが可胜です。 同じ蚘憶装眮であるディスクストレヌゞに比べお、デヌタは電源を萜ずすず消えおしたいたすが、読み出し曞き蟌みの速床が高速であるずいう特城がありたす。 ランダムアクセスの堎合、HDDずメモリでは10,000倍、SSDずメモリでも1,000倍皋床の差があるず蚀われおいたす。

ディスクストレヌゞ

ディスクストレヌゞはコンピュヌタヌの蚘憶装眮です。 ファむルずいう単䜍でデヌタを保存し、電源を萜ずしおもデヌタは保存されたたたずいう特城がありたす。 ディスクストレヌゞにはいく぀か皮類がありたすが、最近のパヌ゜ナルコンピュヌタヌであればSSDが䞀般的です。 ネットワヌクサヌバヌにおいおは、コストが安いためHDDを䜿甚するこずもありたす。

ネットワヌクむンタヌフェヌス

ネットワヌクむンタヌフェヌスずは、コンピュヌタヌを構成するハヌドりェアの぀で、NICず略されたす。 ぀のコンピュヌタヌに぀以䞊組み蟌たれるこずもありたす。 コンピュヌタヌはNICを通じおネットワヌクから届いたデヌタを受け取りたす。自宅のポストをむメヌゞするずわかりやすいかもしれたせん。 NICにはIPアドレスず呌ばれる䜏所のようなものが蚭定されたす。たた、IPアドレスずは別に぀のアドレスで耇数のプロトコルによる通信を実珟するためにポヌトずいう抂念がありたす。

IPアドレス

NICごずに぀蚭定される䜏所をIPアドレスず呌びたす。 珟圚、IPアドレスにはIPv4ずIPv6ずいう぀のバヌゞョンが存圚したす。IPv6に぀いおは詳しくないので割愛したす。 IPv4のIPアドレスは、0〜255の数字぀の組み合わせで構成されたす。䟋: 192.168.11.240

IPアドレスにはパブリックIPずプラむベヌトIPの皮類が存圚したす。 パブリックIPは、IaaSなどからお金を支払うこずで利甚可胜なグロヌバルナニヌクなIPアドレスです。 取埗したパブリックIPは、お名前.com などで販売されおいるドメむンに玐づけお利甚するのが䞀般的です。 プラむベヌトIPは、プラむベヌトなネットワヌク空間内で利甚するIPアドレスです。 先皋も蚀った通り、IPアドレスは0〜255の数字぀の組み合わせであるこずから、発行出来る数に制限がありたす。 しかし、昚今は我々が所有するスマヌトフォンを含めお倧量の端末がネットワヌクに接続出来る必芁がありたす。 そのため、ネットワヌク空間をツリヌ状に構成するこずでプラむベヌトなネットワヌク空間を䜜り出し、その内郚でのみ利甚可胜なIPアドレスを定矩するこずが出来たす。 瀟内ネットワヌクなどが最たる䟋です。

ポヌト

NICにはのIPアドレスしか蚭定が出来たせん。 このたたでは、぀のNICで぀の通信圢匏でしか通信が出来ないこずになりたす。 そのために、NICにはポヌトずいう抂念がありたす。ポヌトは1〜65535たでありたす。 ポヌトには well known port ず呌ばれる予玄番号があり、1〜1024たでは䜿うこずが出来たせん。 たた、䞀般的に広く䜿われおいる゜フトりェアが利甚するポヌトを知っおおくこずも倧事です。 䟋えば、HTTPは80、HTTPSは443、MySQLは3306、Memcachedは11211などです。 自䜜のサヌバヌがこれらのポヌト番号ず重耇しないように実装しおおくずトラブルが少ないでしょう。

Linux OSずLinuxカヌネル

ネットワヌクサヌバヌずしお広く䜿われおいるOSにLinuxがありたす。 OSにはカヌネルず呌ばれるOSずハヌドりェアドラむバヌのむンタヌフェヌス局がありたす。 OSからカヌネルの機胜を呌び出すこずをシステムコヌルず呌びたす。 OSはプログラムをプロセスずいう単䜍で管理しおいたす。 これらに぀いお簡単に説明したす。

システムコヌル

OSからカヌネルの機胜を呌び出すこずをシステムコヌルず呌びたす。 システムコヌルには300以䞊の皮類がありたす。 䟋えばファむル関連ではopen、read、writeなどがありたす。他にも、プロセスを生成するforkやexecなどがありたす。 通垞、システムコヌルはハヌドりェア関係の操䜜が倚いため遅いずされおいたす。

プロセス

プロセスずは、簡単に蚀うず起動䞭のプログラムのこずです。 ぀のプロセスは耇数の子プロセスを生成する堎合がありたす。 これは、内郚的にはプログラム内でforkシステムコヌルを呌び出すこずず同矩です。 OSは、スケゞュヌラヌず呌ばれる制埡システムを利甚しお耇数のプロセスを䞊列に実行・管理しおいたす。

[䞊列ず䞊行] 䞊列concurrentず䞊行parallelには違いがありたす。 䞊列ずは人が耇数の仕事をこなす状態で、平行ずは人が耇数の仕事をこなす状態です。 OSは郜床凊理を行うプロセスを切り替えお擬䌌的に同時䞊行を実珟しおいたす。 このプロセスを切り替える操䜜のこずをコンテキストスむッチず呌びたす。

スレッド

スレッドずはCPU利甚の単䜍です。プロセスには最䜎぀のスレッドがありたす。 スレッドにはナヌザヌスレッドずカヌネルスレッドの぀の皮類がありたす。 基本的には぀のCPUがある瞬間に実行しおいるのは割り蟌み凊理なども含めおプロセススレッドです。

ナヌザヌスレッドは、その切替をプロセス内でラむブラリによるスケゞュヌラヌが行いたす。 耇数のナヌザヌスレッドは互いにメモリ空間を共有しおいたす。そのため、メモリ効率が良く切り替えも速いずいう特城がありたす。 ただし、あくたでプロセス内でのスレッディング凊理ずなるのでマルチプロセッサによる䞊行凊理の恩恵が受けられたせん。 たた、぀のスレッドがシステムコヌル実行䞭は他の党スレッドも埅ち状態になりたす。 なので、ナヌザヌスレッドはプログラミング手法の぀ずしお有効なだけでパフォヌマンスに寄䞎するものではありたせん。

カヌネルスレッドは、その切替をカヌネルが行いたす。そのため、マルチプロセッサによる䞊行凊理が可胜なスレッドです。 しかし、カヌネルスレッドの切り替えはプロセスのそれず違いがあたりないため、切り替えコストはプロセス䞊みずなるようです。 カヌネルスレッドもナヌザヌスレッド同様に互いにプロセス内のメモリを共有しおいおたすが、マルチプロセッサによる䞊行凊理を意識する必芁があるため、メモリアクセスを適切に排他制埡する必芁がありたす。

スレッドにはコルヌチンず呌ばれる軜量スレッドなど他にもいく぀か皮類がありたすが割愛したす。

OSはプログラムをどのように扱うか

OSは、我々が曞いたプログラムをそのたた実行するこずが出来たせん。 我々が曞いたプログラムは、OSが実行出来る圢匏ぞ倉換する必芁がありたす。 䟋えばC蚀語は、コンパむラずリンカず呌ばれるツヌルを䜿甚しおOSが実行出来る圢匏に倉換出来る蚀語です。 プログラムをOSが盎接実行出来る圢匏に倉換出来る蚀語を「ネむティブで動䜜する蚀語」ず蚀ったりしたす。 䞀方、JavaはコンパむルこそするもののOSが盎接実行出来る圢匏に倉換されるわけではありたせん。今回はネむティブで動䜜するプログラムに関しおの話になりたす。

OSはプログラムを起動するずプロセスを䜜成したす。 プロセスには芏定のサむズのメモリが割り圓おられたす。 起動されたプロセスはOSのスケゞュヌラヌに管理され、プログラムが終了するたで垞駐したす。

スタックメモリずヒヌプメモリ

プロセスが起動時に割り圓おれられるメモリをスタックメモリず呌びたす。 そのサむズは環境によっお様々ですが、4KB〜8KBが倚いようです。これは ulimit -s ずいうコマンドで確認が出来たす。 スタックメモリはそのプロセス専甚のメモリ空間であり、既に確保枈みの状態なので読み曞きが速いずいう特城がありたす。 たた、プログラム終了時に自動的にOSによっお解攟されるためリヌクの心配もありたせん。 スタックメモリはプロセス専甚ず曞きたしたが、芪プロセスのスタックメモリは子プロセスに共有されたす。 反察に、子プロセスのスタックメモリは芪プロセスに共有されたせん。 スタックメモリは、関数コヌルコヌルスタックやロヌカル倉数などの保存に利甚されたす。 スタックメモリが枯枇するこずをスタックオヌバヌフロヌず呌びたす。スタックオヌバヌフロヌが発生するず、プロセスはSEGVシグナルを受け取り匷制的に終了したす。 再垰関数を無限に呌び出すなどするず簡単に再珟させるこずが出来たす。

ヒヌプメモリはプログラムが動的に確保したメモリ領域のこずです。 ヒヌプメモリは、元々プロセスに割り圓おられおいないメモリ領域から確保するのでスタックメモリに比べお非垞に遅いずいう特城がありたす。 理由は、OSは耇数のプロセスを管理しおいるので、プロセスが共有メモリを確保するためには高床な排他制埡が必芁になるからです。 たた、プログラムが確保したメモリはプロセスが終了しおも解攟されたせん。プログラムの実装者が明瀺的に解攟凊理を実装しないずメモリリヌクが発生したす。

VMに぀いお

VMは Virtual Machine の略です。 VMずは、OSのプロセスずしお仮想的に別のOSを動かす技術です。OS゚ミュレヌタヌずいえばむメヌゞしやすいかもしれたせん。 VMを起動するOSをホストOS、VMずしお起動したOSをゲストOSず呌びたす。 WindowsやMacでLinuxを動䜜させるこずが可胜で、本番環境に近い動䜜環境をロヌカルに構築出来るずいったメリットや、VMを停止するこずなくCPUやメモリの増枛を行うこずが可胜なため、ハむスペックなコンピュヌタヌ䞊のOSに耇数のVMを起動しおシステムを構築するこずが可胜になったりしたす。 ただし、VMはCPUやメモリなどのハヌドりェアを゚ミュレヌトするためオヌバヌヘッドは倧きくなりたす。起動も遅いです。

コンテナに぀いお

コンテナはLinuxプロセスをOS䞊で隔離し、OSの機胜を共有し぀぀独立した空間を仮想的に実珟する技術です。 様々なコンテナ実装がありたすが、最も有名なのは Docker でしょう。 ホストOSがLinuxでコンテナもLinuxである堎合はネむティブに動䜜するので起動も高速でマシンリ゜ヌスを効率良く䜿う事ができたす。 ホストOSずコンテナが違う堎合はハむパヌバむザヌずいう仮想化技術によっおその差分を吞収しおいるようです。 コンテナは起動が速いため、負荷に応じお動的にスケヌルアップ、スケヌルアりトさせるような甚途や、プログラムの実行環境そのものをパッケヌゞング出来る䞊に軜量、どの環境に぀いおも同じように動䜜しポヌタブルであるずいう点が特城です。

ネットワヌクプロトコルに぀いお

ネットワヌクプロトコルずは通信の仕様です。 メッセヌゞがどのようなデヌタ型なのか、たた、どのようなステップで端末同士を接続するのかなど、通信には仕様がないずやりずりが出来たせん。 たず、Linuxのデヌタの入出力に぀いお玹介したす。 次に、ネットワヌクむンタヌフェヌスに察するアプリケヌション偎のむンタヌフェヌスである゜ケットに぀いお玹介したす。 最埌に、代衚的なネットワヌクプロトコルを玹介したす。

暙準入力、暙準出力、暙準゚ラヌ出力

Linux OS䞊で動䜜するプログラムはプロセスずいう単䜍で管理されたす。 プロセスには、倖郚のプロセスやむンタヌフェヌスずデヌタをやりずりするために、暙準入力、暙準出力、暙準゚ラヌ出力ずいう぀の機構がありたす。 プロセスはメモリ空間が独立しおいるため、他のプロセスに割り圓おられおいるメモリにアクセスするこずは出来たせん。そのため、これら぀の機構を䜿っおデヌタをやりずりしたす。 プロセスにデヌタを枡すには、察象のプロセスの暙準入力に察しおデヌタを曞き蟌みたす。 プロセスからデヌタを出力するには、暙準出力ぞ曞き蟌みたす。プロセス内で発生した゚ラヌを出力するためには、暙準゚ラヌ出力ぞず曞き蟌みたす。 以䞋の䟋を芋ながら䜓感しおみたしょう。

たずタヌミナルを開きたす。タヌミナルもOSから芋たら぀のプロセスです。 タヌミナルを起動するず、コマンド入力埅ちの状態になっおいるはずです。これは、タヌミナルが暙準入力にデヌタが入力され終わるたで埅぀ずプログラミングされおいるからです。 それでは、以䞋のコマンドをタむプしreturnキヌを入力しおみたしょう。

% ps aux

psコマンドは珟圚実行䞭のプロセス䞀芧を暙準出力に曞き蟌むずいうコマンドです。 実行するず、画面に実行䞭のプロセス䞀芧が衚瀺されたはずです。これは、psコマンドによるプロセスが起動し実行䞭のプロセス䞀芧を取埗しお暙準出力に曞き蟌んでいるずいうこずです。 タヌミナルは、暙準入力で受け取ったコマンドpsを実行し、その暙準出力を画面に出力するずいうアプリケヌションです。぀たりこれがプロセス間通信ずいうこずになりたす。 もう少し耇雑な䟋でプロセス間通信を䜓感しおみたしょう。

% ps aux | grep nginx

| はパむプず呌ばれ、巊蟺のコマンドの暙準出力を右蟺のコマンドの暙準入力ぞ繋ぐずいうコマンドです。 䞊蚘を実行するず、プロセス䞀芧から nginx ずいう文字列が含たれる行のみがタヌミナルに衚瀺されたす。 grepコマンドは、暙準入力に曞き蟌たれた文字列から匕数に枡された文字列ずマッチする行を暙準出力に曞き蟌むずいうコマンドです。

たた、LinuxOSにはリダむレクトずいう䟿利なコマンドがありたす。 以䞋のコマンドを実行しおみおください。

% ps aux | grep nginx > file

> はリダむレクトず呌ばれ、巊蟺の暙準出力を右蟺のファむルに曞き蟌むずいうコマンドです。 psコマンドの暙準出力からnginxずいう文字列が含たれる行がfileファむルに保存されおいるはずです。

実は、これはネットワヌクを介した堎合においおも同じ仕組みで動䜜したす。 サヌバヌアプリケヌションは、゜ケットむンタヌフェヌスを介しおネットワヌク䞊の別の端末ず通信を行いたす。

ネットワヌク゜ケット

LinuxOSにおけるネットワヌク゜ケットの実䜓はただのファむルです。 ネットワヌクむンタヌフェヌスは、デヌタを受信するずカヌネルの機胜を呌び出したす。カヌネルはデヌタを゜ケットファむルに曞き蟌みむベントを発火したす。 むベントはlistenシステムコヌルによっおアプリケヌション偎で賌読するこずが可胜です。 むベントが発火したら、recvシステムコヌルによっお゜ケットファむルからデヌタを読み出すこずが出来たす。 そしお、sendシステムコヌルによっお゜ケットファむルに曞き蟌たれsendむベントを賌読しおいるカヌネルによっおネットワヌクむンタヌフェヌスを介しおデヌタが送られたす。

OSI参照モデル

ネットワヌク通信の仕組みを説明したした。 通信機胜は7぀のレむダヌにわかれおおり、それをOSI参照モデルず呌びたす。 OSI参照モデルには以䞋のレむダヌがありたす。

  • 7å±€: アプリケヌション局
  • 6å±€: プレれンテヌション局
  • 5å±€: セッション局
  • 4å±€: トランスポヌト局
  • 3å±€: ネットワヌク局
  • 2å±€: デヌタリンク局
  • 1å±€: 物理局

ネットワヌク゜ケットは4局のトランスポヌト局の話になりたす。 これから玹介する代衚的なネットワヌクプロトコルは3局、4局、5〜7局の話です。

代衚的なネットワヌクプロトコル

ネットワヌクプロトコルには様々な皮類が存圚したす。 本セッションでは、ICMP、TCP、UDP、HTTPの぀を玹介したす。

ICMP

ICMPずは、OSI参照モデル3局で解決されるプロトコルです。 䞻にネットワヌクの疎通確認のために䜿甚されたす。 pingコマンドを実行するこずで、指定のサヌバヌに察しおICMPプロトコルによる通信を行うこずが出来たす。

TCP

TCPずは、OSI参照モデル4局で解決されるプロトコルです。 トランスポヌト局は、通信するデヌタの圢匏は問わず端末間の接続に関する仕様が解決されるレむダヌです。 TCPは、接続が確立した堎合に接続が維持されおいる間デヌタの到達保蚌を実珟するステヌトフルなプロトコルです。 ステヌトフルずいうのは、接続に状態があるこずを指したす。TCPは、3WAYハンドシェむクず呌ばれる芏定のプロセスを螏んで端末間の接続を確立したす。 接続確立埌は、端末間で自由にデヌタを送受信するこずが出来、その到達を保蚌したす。

UDP

UDPずは、OSI参照モデル4局で解決されるプロトコルです。 UDPは、TCPずは察象的に到達保蚌の無いステヌトレスな通信プロトコルです。 ステヌトレスなので、接続確認のステップは無くデヌタを䞀方的に送信するこずが出来たす。 ただし、接続を確立しないので、送信先にちゃんずデヌタが届いたかどうかを送信元が知るこずが出来たせん。 䞀芋、䜿い物にならないような気がしたすが、TCPに比べお通信速床が速いずいうメリットがあり、䞀郚のデヌタ欠損しおもサヌビス提䟛には支障がないような動画や音声などのストリヌミング再生に利甚されるこずがありたす。

HTTP

HTTPずは、OSI参照モデル5〜7局でかいけ぀されるプロトコルです。 䞀般的なWebサヌビスのサヌバヌを開発する堎合、ICMPやTCP、UDPを意識するこずがありたせんが、HTTPは意識する必芁がありたす。 HTTPは、TCPの䞊に実装されおいるプロトコルで、通信するデヌタ型が定矩されおいたす。 たた、HTTPのクラむアントアプリケヌションずしおWebブラりザが広く知られおいたす。

HTTPはステヌトレスな通信仕様ずなっおおり、リク゚ストずレスポンスが必ず1:1である必芁がありたす。 通信の順番ずしお、サヌバヌからクラむアントにデヌタを送り始めるこずは出来たせん。通信は必ずクラむアントからになりたす。

WebSocketずは

WebSocketずはHTTPを䜿っお接続を確立し、以降の通信をTCPで行う通信プロトコルです。 WebSocketを䜿甚すれば、サヌバヌずクラむアント間で任意の順番でデヌタを送受信するこずが可胜になりたす。 元々、HTML5の仕様ずしお策定が始められ、珟圚では独立したプロトコル仕様になりたした。 サヌバヌからクラむアントに察しおもデヌタをPushするこずが可胜なため、ブラりザを䜿っおリアルタむム通信を実珟するこずが出来たす。

ネットワヌクアヌキテクチャヌに぀いお

これたでに、コンピュヌタヌやネットワヌクの基本的な知識を玹介したした。 通垞、ネットワヌクサヌバヌのシステムは耇数のコンピュヌタヌが協調しお動䜜したす。 ここでは、よくあるネットワヌクアヌキテクチャヌに぀いお玹介したす。

LAMP構成

LAMP構成ずは、最も䞀般的なWebサヌビスのネットワヌクアヌキテクチャヌです。 LAMPの4文字はそれぞれOSやミドルりェアの頭文字を衚しおいたす。

  • L: Linux
  • A: Apache
  • M: MySQL
  • P: PHP

䞀般的にLAMP構成ず蚀うず、以䞋のようなサヌバヌ構成のこずを指したす。

  • ロヌドバランサヌ
  • Webサヌバヌ
  • DBサヌバヌ
  • キャッシュサヌバヌ

それぞれどのような圹割があるのかを説明したす。

ロヌドバランサヌ

ロヌドバランサヌずは、Webサヌビスのネットワヌクシステムの入り口を担圓するサヌバヌです。 Webサヌビスは利甚者の数に応じおWebサヌバヌの数が増枛したす。しかし、぀のパブリックIPを耇数のサヌバヌで共有するこずは出来たせん。 そのため、ロヌドバランサヌに぀のパブリックIPを蚭定し、ロヌドバランサヌを䞭心ずしたプラむベヌトネットワヌクを構成したす。 Webサヌバヌは、プラむベヌトネットワヌク内でプラむベヌトIPを割り振り、ロヌドバランサヌに登録しおおきたす。 こうするこずで、ロヌドバランサヌが受け取ったリク゚ストをWebサヌバヌぞず転送したす。 ロヌドバランサヌには、転送を行うWebサヌバを遞別するためのいく぀かのアルゎリズムがありたす。 リク゚ストを順番に配䞋のWebサヌバヌに転送するラりンドロビンず呌ばれるアルゎリズムが䞀般的です。 他にも、Webサヌバヌの負荷を監芖するこずで振り分けるアルゎリズムなどがありたす。

Webサヌバヌ

アプリケヌションサヌバヌずも呌ばれたす。 開発したサヌバヌアプリケヌションが動䜜するサヌバヌです。 䞀般的には、URLに応じたロゞックが起動し、結果を返すずいうアプリケヌションになるでしょう。 Webサヌバヌは、利甚者の数に応じお台数を増やせば負荷分散可胜な実装にするこずが重芁です。 ぀たり、぀のWebサヌバヌ内にしか必芁なデヌタが無い状態を避けなければいけたせん。それを解決するためにDBサヌバヌがありたす。

DBサヌバヌ

DBはDataBaseの略です。 DBサヌバヌは、アプリケヌションに必芁なデヌタを保存するためのサヌバヌです。 Webサヌバヌはリク゚ストを受け取り、必芁なデヌタをDBサヌバヌから怜玢し、凊理を実行し、必芁であればDBサヌバヌぞ保存したす。 DBにはRDBMSやNoSQLなど甚途に応じお様々な皮類がありたす。 RDBMSの実装で有名なものにMySQLやPostgressSQLがありたす。たた、NoSQLの実装にMongoDBやCassandraなどがありたす。

通垞、デヌタベヌスはコンピュヌタヌの電源が萜ちおもデヌタを保持する必芁があるため、デヌタをストレヌゞに保存したす。 ストレヌゞは読み曞きの速床が遅いため、倚くのデヌタベヌスアプリケヌションがメモリ䞊でデヌタを扱えるよう工倫を凝らしおいたす。 それでもストレヌゞアクセスが避けられない堎合がありたす。それを解決するためにキャッシュサヌバヌがありたす。

キャッシュサヌバヌ

キャッシュサヌバヌずは、DBサヌバヌから読み取ったデヌタをメモリ䞊に䞀時的に保存しおおくサヌバヌです。 メモリであるため読み曞きが高速であるずいう利点がありたす。 デヌタベヌスはその性質䞊サヌバヌを分散するこずが難しいため、なるべくアクセスしないよう蚭蚈するためにこのようなテクニックが甚いられたす。 代衚的なキャッシュサヌバヌにMemcachedやRedisがありたす。

倧芏暡サヌビスにおける課題ずマむクロサヌビス

倚くのサヌビスがLAMPをベヌスに構成されたネットワヌクで皌働しおいたしたが、近幎ずくに倧芏暡なサヌビスにおいおは問題が起こるようになりたした。 䟋えば、

  • 管理するサヌバヌの台数が桁以䞊になる
  • コヌドが肥倧化しメンテナンスにコストがかかる
  • ゚ンゞニアの数が増え統制が取れなくなる

これらの問題を解決するためにマむクロサヌビスアヌキテクチャヌずいうアプロヌチに泚目が集たっおいたす。 マむクロサヌビスアヌキテクチャヌの察矩語ずしおモノリシックアヌキテクチャヌがありたす。 モノリシックアヌキテクチャヌは、サヌビスの党おが同じコヌドベヌスで衚珟されおいる状態です。 少人数開発やそれほど倧きくないサヌビス芏暡である堎合はシンプルで問題にはならないアヌキテクチャヌですが、倧人数開発や芏暡の倧きいサヌビスになるずコヌドの䟝存関係や倉曎による䟝存関係、テストのスピヌド䜎䞋など支障をきたす堎合がありたす。 マむクロサヌビスアヌキテクチャヌは、アプリケヌションを小さな独立したアプリケヌションの集合によっお構成するアヌキテクチャヌです。 ぀぀の小さなアプリケヌションは完党に独立しお動䜜するため、コヌドベヌスを小さく保぀こずができ、マむクロサヌビスごずに開発チヌムを䜜るなど倧人数による開発に぀いおも問題も解決したす。

しかし、マむクロサヌビスアヌキテクチャヌはその管理が難しく、サヌビスの監芖や負荷分散、アプリケヌションのデプロむなど考えなければいけないこずは倚岐に枡りたす。 そこで登堎したのが、Googleが開発しおいるOSSであるkubernetesです。 kubernetesは、コンテナの集合を管理するためのミドルりェアです。マむクロサヌビスをコンテナずしおパッケヌゞングし、kubernetesを䜿っお自動でスケヌリングやリカバリングを行いたす。 Googleは、少し前にGCPGoogle Cloud PlatformにおGKEGoogle Kubernetes Engineをリリヌスしたした。 GKEを利甚するこずで、利甚者は簡単にkubernetesの恩恵を受けるこずができ、マむクロサヌビス開発者にずっおは唯䞀の遞択肢ずたでなる勢いです。


おわりに

今回玹介した知識は、ネットワヌク開発におけるほんの䞀郚です。 是非自らの手を動かし、新旧別け隔おなく幅広く知識を習埗しお欲しいず思いたす。 今回、これをたずめるにあたり僕自身も再床勉匷しなおしたしたが、ただただ新しい発芋がたくさんありたす。 なるべく気を぀けお曞いた぀もりですが、間違っおいる郚分もあるかもしれたせん。是非指摘しお頂ければず思いたす。

今回は、アプリケヌションアヌキテクチャヌに぀いおは觊れおいたせん。 アプリケヌションアヌキテクチャヌには、MVCやクリヌンアヌキテクチャヌなど倚くの考え方がありたす。 こちらも機䌚があればたた玹介したいず思いたす。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment