Just another WordPress site
OSI参照モデルとは、ノード（コンピュータ）間の通信を定めた規格のことで、通信に必要な要素を７つの層に分けて規定しています。
この規格により、異なるベンダの機器を使用していたとしても通信が行えるようになっています。
OSI参照モデルについて、応用情報処理技術者試験で出てくるレベルの知識はないと、ネットワークエンジニアと会話することができません。
その意味で、アプリケーションエンジニアであったとしても、必要な知識になります。
今回、OSI参照モデルの規定内容・主なプロトコル・主な通信装置を一つの表にまとめましたので、公開します。
この表で知識を整理するだけでも、応用情報処理技術者試験の問題は概ね解けるはずです。
いかがでしたでしょうか。
今回は、自分の頭を整理するために作っていた一覧表を公開しました。
このような一覧表は時々作成するので、これからも公開していきたいと思います！
システムの運用においてトラブルの対策を考える際、インパクトが大きいトラブルに対しては大きな労力を、そうではないトラブルに対しては小さな労力をかけるのが効率的です。
ここで、ホビーの売買サイトの運用を例に挙げて説明します。
例えば、エンドユーザーが直接触る画面において、金額計算を間違えてしまった場合、直接クレームに繋がってしまいます。
このようなインパクトの大きいトラブルの発生が想定される場合、予め念入りにテストしたり、本番リリース後にもテストを行ったりして、トラブル発生を防ぐために大きな労力をかける必要があります。
その結果として、実際にそのようなトラブルが起こる可能性は小さくなります。
逆に、管理者しか触らない画面において誤字がある、という程度のトラブルであれば、謝罪して修正してリリースすることで、大事にならずにトラブルを解消することができます。
このような軽微なトラブルについては前述のような念入りなテストを行ったり体制を用意する必要性は薄く、他のトラブルの対策に労力を割いた方が効率的になります。
しかし、トラブルのインパクトの大きさを過小評価してしまった場合、本来かけるべき労力をかけずに、高確率で大きなトラブルが発生してしまいます。
例えば、１日の売上記録を他システムへファイル連携するバッチ処理を想定します。
当該の他システムが開発中であり、その他システムではただファイルを受信しているだけであれば、ファイルの中身が誤っていたとしても後で時間をかけて検証して修正すれば、大きなトラブルになることはありません。
このトラブルで済むのであれば、開発者が作成したデータでテストで済ませ、リリース後も後で時間をかけて結果を検証する、という程度の労力でも通常は問題ありません。
しかし、開発中でファイル未取り込みだと思っていた当該の他システムが、実はファイル取り込みも行っている、しかも管理者がシステムテストのために処理結果を見ている、となった場合、システムテストのスケジュールに影響を与えてしまうというトラブルになってしまいます。
更に、取り込んだデータの修正も必要になるため、リカバリーにも時間がかかるという厄介なトラブルになってしまいます。
このレベルのトラブルになってしまうのであれば、本番データを想定したテストを事前に行い、リリース時も事前にファイルを出力し、出力結果に問題がある場合はファイル送信を差し止める、といった対応が必要になります。
前述のような少ない労力の対策では、本番で厄介なトラブルが発生する確率が高くなってしまいます。
このように、トラブルのインパクトの大きさを過小評価してしまうと、大きなトラブルに発展してしまう可能性が高まります。
それを防ぐために、トラブルのインパクトの大きさは予め有識者に確認しておく、確認できない場合は大きなトラブルが発生することを想定して労力をかける、ということが必要になります。
いかがでしたでしょうか。
今回は実務で発生したことを元にして、得られた教訓を記事として残しました。
実務から得られる教訓は貴重なものですので、これからも文章として残していきたいと思います。
経験が浅い技術者は、システムを構築する際、ユーザーの目から見える機能（機能要件）を満たすことのみを考えがちです。
しかし、システムが価値を生み出すためには、システムが安定的に運用される必要があります。
システムの安定運用を実現するための要件を、「非機能要件」と呼びます。
要件は、国際規格ISO/IEC 9126(JIS X 0129)においては、「機能性」「信頼性」「使用性」「効率性」「保守性」「移植性」の６つの特性に分類できます。
この内、「機能性」を除いた５つの特性が「非機能要件」とみなすことができる特性です。
これらの分類を詳しく書くと以下の通りです。
この国際規格は、情報処理技術者試験で出題されます。
試験対策としては、６つの特性とその概要さえ覚えておけば十分です。
また、実務に従事する上では、６つの特性とその概要を理解した上で、副特性に書かれている観点を網羅的に見て非機能要件を洗い出すことが重要です。
現場に要件定義書のテンプレートがあるのであれば、その現場のテンプレートに従って非機能要件を記述すれば良いのですが、テンプレートが無い場合はこの国際規格をベースに要件定義を進めるのが良いでしょう。
なお、要件定義の後の基本設計でも、非機能要件をベースとした非機能設計が必要になります。
非機能設計についても非機能要件と同じことが言えます。
いかがでしたでしょうか。
今回は、見逃されがちな非機能要件について触れました。
特に、新規のシステムの上流工程に携わるのであれば絶対に知っておきたい知識なので、携わる予定があるのであればどのような特性があるのか今一度眺めてみると良いでしょう。
これからも役に立つ技術の解説を書いていこうと思います！
この記事では、暗号化が必要な理由や共通鍵暗号方式・公開鍵暗号方式の概要、SSLの仕組みの概要について書きます。
暗号化については、ノード（端末やサーバ等、他の機器との通信を行う主体を指す）間の通信に着目した内容となります。
ノード間の通信内容は、Wiresharkのようなパケットキャプチャ（ソフトウェア）で確認することが可能です。
どのような形で確認できるのかは、Googleの画像検索で調べればイメージがわきやすいと思います。
そして、ユーザ/パスワードのような重要な情報を送受信する際も、同じようにパケットキャプチャで通信内容を見ることができてしまいます。
もし、そのような重要な情報が平文（生データ）で送受信されていたとしたら、それはセキュリティ面で重大なリスクとなります。
例えば、ユーザ/パスワードを盗み見た第三者が、なりすましでログインすることができてしまいます。
それを防ぐために、「鍵」と呼ばれる通信を行う者同士であらかじめ共有されたデータを使用し、特定のアルゴリズムにより通信するデータを暗号文に変換します。
そうすることで、第三者に通信内容を盗み見られたとしてもその中から重要な情報を取得されるのを防ぐことができます。
「鍵」を持たない第三者が暗号文を見ても内容を理解できない、という所が重要です。
暗号化の方式は大きく分けて二つあり、「共通鍵暗号方式」と「公開鍵暗号方式」があります。
これは、あらかじめ２者間で共有された共通鍵を使用する方式です。
図解すると以下のようになります。
この方式は、方式が単純であることから暗号化・復号を早く行うことができるのが利点ですが、多くの鍵を用意する必要がでてきてしまう欠点があります。
上記の図の通りなのですが、２者の組み合わせ毎に鍵を用意する必要が出てきてしまうため、n(n-1)/2の分だけ鍵が必要になってしまいます。
（各々のノード（n）は、他の各々のノード（*(n-1)）に対して鍵を用意する必要がある。ただし、２者間で別々の鍵を用意する必要はない（/2）。）
これは、それぞれの主体が秘密鍵と共有鍵を管理し、通信を行う時に通信相手に共有鍵を渡して通信を行う方式です。
図解すると以下のようになります。
この方式は、少ない鍵で通信を行うことができる利点がありますが、方式が難しく暗号化・復号を早く行うことができません。
必要な鍵の数は、それぞれの主体が秘密鍵と共有鍵の２つの鍵さえ持っていれば良いので、必要なのは2nの分のみです。
インターネット上で通信を安全に行う仕組みとして、SSLと呼ばれる仕組みがあります。
SSLは、インターネットプロトコルであるhttpsにも使われています。
（重要な情報を送受信する時にはhttpsを使うべきであると言われたことがあると思いますが、httpsが安全な理由はSSLを使っているからです）
SSLでは、先で説明した共通鍵暗号方式と公開鍵暗号方式を利用しています。
また、サーバ証明書を利用するのも特徴です。
サーバ証明書とは、認証局（サーバの正当性を証明する第三者の企業）からサーバに対して付与されるものであり、通信を行うサーバが正当なものである（犯罪等に悪用されることがない）ことを証明するデータです。
仕組みは以下の通りです。サーバ側で管理する鍵は2つのみで済む、かつ公開鍵暗号方式は共通鍵（短い文字列）に対してのみ用いられるため高速、と共通鍵暗号方式と公開鍵暗号方式の良いとこ取りの方式となっています。
いかがでしたでしょうか。
暗号化は複雑なアルゴリズムで書かれており、汎用的なライブラリも用意されているので、アプリケーションを作成する技術者が意識することは通常ありません。
しかし、ライブラリを使用する時に暗号化方式の概要の知識がある方が理解が進むため、概要の知識だけでも知っておいた方が無難です。
また、情報処理技術者試験でも問われる内容となりますので、試験対策という意味でも知っておく必要があります。
これからも役に立つ技術の解説を書いていこうと思います！
今回は、データベースの障害復旧について、情報処理技術者試験で問われる一般論を書いていきます。
また、関連するファイル・概念の説明もついでに行います。
障害回復操作を開始すべき時点。一定時間感覚で訪れる。
なお、チェックポイントでは、データベースの状態や障害回復操作を開始すべき時点の情報を保存したチェックポイントファイルが生成される。
障害復旧のためにデータベースのある時点の内容全体をコピーしたファイル。
直前のチェックポイント時点でコミットされていないトランザクションについては障害復旧が必要になる。
更新前のログファイルを用いて処理開始時点の状態に戻す。
（ロールバック）
バックアップファイルを適用してから、更新後のログファイルを用いてコミット時点の状態に進める。
（ロールフォワード）
ファイルやメモリの内容を出力したファイルであるが、DBMSにおいては各テーブルの定義情報や全レコードを出力したファイルのことを指す。
実務では、他の環境にデータを移したり、テスト環境等で簡易的にバックアップを取ったりする時に用いる。
（プログラム開発者にとってはこれが一番馴染み深いと思います。MySQLではSQL文（DDL文＋INSERT文）がそのままダンプファイルとして出力されるので、中身も理解しやすいです。）
いかがでしたでしょうか。
今回書いた内容は試験頻出であり、データベースが試験範囲に含まれる試験区分であればITパスポートでも問われる内容なので、情報処理技術者試験を受験するのであれば必ず押さえておきたいポイントです。
また、実務でも、基本設計工程やインフラ作業に携わるのであれば知っておく必要があります。
今回の記事が理解の助けになれば幸いです。