データベースの障害復旧の基礎

今回は、データベースの障害復旧について、情報処理技術者試験で問われる一般論を書いていきます。
また、関連するファイル・概念の説明もついでに行います。

【データベースの復旧に用いるファイル・概念】

・チェックポイント

障害回復操作を開始すべき時点。一定時間感覚で訪れる。
なお、チェックポイントでは、データベースの状態や障害回復操作を開始すべき時点の情報を保存したチェックポイントファイルが生成される。

・バックアップファイル

障害復旧のためにデータベースのある時点の内容全体をコピーしたファイル。

・ログファイル(ジャーナルファイル) データベースの更新前や更新後の情報を書き出したファイル。

【障害復旧方法】

直前のチェックポイント時点でコミットされていないトランザクションについては障害復旧が必要になる。

・障害発生時点でコミットしていないトランザクション

更新前のログファイルを用いて処理開始時点の状態に戻す。
(ロールバック)

・障害発生時点でコミットしているトランザクション

バックアップファイルを適用してから、更新後のログファイルを用いてコミット時点の状態に進める。
(ロールフォワード)

【障害復旧とは直接関係ないが重要なファイル】

・ダンプファイル

ファイルやメモリの内容を出力したファイルであるが、DBMSにおいては各テーブルの定義情報や全レコードを出力したファイルのことを指す。
実務では、他の環境にデータを移したり、テスト環境等で簡易的にバックアップを取ったりする時に用いる。
(プログラム開発者にとってはこれが一番馴染み深いと思います。MySQLではSQL文(DDL文+INSERT文)がそのままダンプファイルとして出力されるので、中身も理解しやすいです。)


いかがでしたでしょうか。

今回書いた内容は試験頻出であり、データベースが試験範囲に含まれる試験区分であればITパスポートでも問われる内容なので、情報処理技術者試験を受験するのであれば必ず押さえておきたいポイントです。
また、実務でも、基本設計工程やインフラ作業に携わるのであれば知っておく必要があります。

今回の記事が理解の助けになれば幸いです。

Visual Studio Codeでdraw.ioを使う

フローチャートやネットワーク図等は、フリーの作図ツール「draw.io」を使うと楽に記述できます。
Excelでも記述はできますが、draw.ioでは各々の図の記述に適した素材が提供されているという特徴があります。
また、draw.ioはブラウザ上での使用が想定されていますが、フリーのコードエディタである「Visual Studio Code」を用いるとローカル上で編集が可能になります。

今回は、使用手順を簡単に紹介していきたいと思います。


1.draw.ioのホームページにアクセスする。

https://app.diagrams.net/

2.ファイルの保存方法を選択する。

今回は「Device」を選択します。これで図がローカルに保存できるようになります。
また、選択後、新規にファイルを作成するかどうか聞かれるので、新規にファイルを作成する(Create New Diagram)を選択します。

3.どのような図を作成するか選択する。

今回は「Flowchart」を選択します。

4.ブラウザ上でファイルを編集してみる。

例えば、図形を追加する場合は、「Shapes -> General」から追加することができます。
また、図形の中に文字を入力したい場合は「右クリック -> Edit」で入力できます。
図を保存したい場合は、画面上部の「Click here to save.」から保存できます。

5.Visual Studio Codeに拡張機能を入れる。

ローカルでVisual Studio Codeを開き、拡張機能の検索画面を開きます。
そして、「draw.io」を検索し、「Draw.io Integration」をインストールします。

6.4でローカルに保存したファイルをVisual Studio Codeで開く。

すると、以下のように、ローカルでdraw.ioの図を編集できるようになります。
図形の追加は「General」から、文字編集は図形をダブルクリックすることで可能です。


いかがでしたでしょうか。

Visual Studio Codeはコードエディタではありますが、サクラエディタのようなテキストエディタというよりも、EclipseやVisual StudioのようなIDEに近く、「軽量IDE」と呼んだ方が実態に近い位です。
そして、IDEと同じように、拡張機能も数多く用意されています。

機会があれば、便利な拡張機能をまた紹介したいと思います!

クラウドコンピューティングの分類

今回はクラウドコンピューティングについて、その概要と分類について書いていきます。

世界的に有名なクラウドコンピューティングサービスとしては、Amazon Web Services(AWS)、Google Cloud Platform(GCP)、Microsoft Azure等が挙げられます。
これらのサービスが実務で使われることも増えています。
また、ここ5年ほどで、情報技術者試験でも、クラウドコンピューティングの概要や分類について知っておかないと解けない問題が出題されるようになりました。

情報技術者試験で問われるレベルの知識がないと会話や情報収集をするだけでも難しくなっており、現代のIT技術者にとって重要な技術となりました。


【クラウドコンピューティングの概要】

クラウドコンピューティングとは、サービス事業者が管理するシステムにインターネットを介して接続することで、目的のサービスを受けるというものです。
月額必要を支払うことで、自社でシステム資源を用意し管理する必要がなくなるというメリットがあります。
可用性等のシステム要件はサービス提供事業者毎に異なり、SLAにより合意します。

クラウドコンピューティングは、仮想化技術によって支えられています。
仮想化技術とは、1台の物理サーバを複数台の仮想的なサーバに分割し、それぞれに別のOSやアプリケーションソフトを動作させる技術のことです。
1台の物理サーバで複数の仮想サーバをコントロールできるため管理が容易になりますが、1台のサーバに処理が集中し競合も起きるため、サーバの利用率やCPUのオーバヘッドは上昇します。


【クラウドコンピューティングの分類】

クラウドコンピューティングのサービス形態は、大きく分けると以下の3つがあります。

■SaaS(Software as a Service)

サービス提供事業者はアプリケーション・ミドルウェア・OS・ネットワーク・ハードウェアを提供・管理する。
利用者はクラウド上のアプリケーションを使用する。
利用者が管理するものはない。
利用者はアプリケーションにおける設定可能範囲内でカスタマイズが可能。
 

■PaaS(Platform as a Service)

サービス提供事業者はミドルウェア・OS・ネットワーク・ハードウェアを提供・管理する。
利用者は、クラウド上で用意されたプログラミング言語・ライブラリ・サービス・ツールを使用し、アプリケーションを実装する。
利用者はアプリケーションを管理する。
利用者はミドルウェアにおける設定可能範囲内でカスタマイズが可能。
 

■IaaS(Infrastructure as a Service)

サービス提供事業者はOS・ネットワーク・ハードウェアを提供・管理する。
利用者は、クラウド上で用意されたインフラ資源を利用し、システムを構築する。
利用者はアプリケーション・ミドルウェアを自前で用意・管理する。
利用者はOS・ネットワークに関して決められた範囲内でカスタマイズが可能。
(OS・ネットワークも完全に利用者が自前で用意する場合もある)


クラウドコンピューティングの分類について、記憶を定着させたり情報を整理するために簡単な表を作りましたので、よろしければこちらも参考にしてみてください。

■SaaS・PaaS・IaaSの概要

※頭文字を取って「SPI」と覚えると、より覚えやすいかもしれません。
 ちなみに、「SPI」は就職試験で使われる有名な適性試験の名前です。  

■SaaS・PaaS・IaaSでの資源の扱い


いかがでしたでしょうか。

クラウドコンピューティングについて、情報処理技術者試験で問われるレベルのことを書いてみました。
現代でインフラエンジニアとして仕事をするのであれば、より深い知識が必要になります。
ベンダー資格も充実しているので、興味があれば学ぶことをお勧めします。

シーケンス図の使い所とPlantUMLの紹介

UMLの一つであるシーケンス図は、クラスやオブジェクト間のやりとりを時間軸に沿って表現する図です。
複数の処理が並列で走る場合に、処理タイミングを整理する上で便利な図です。

例えば、マルチスレッドプログラムを開発している時に便利です。
シーケンス図を書くと、ややこしいスレッド間の関連をわかりやすく整理することができます。
マルチスレッドを取り扱う解説書やシーケンス図は良く出てくるのですが、保守開発等で自分がコーディングする時にも頭の整理のために役立てることができます。

以下では、javaでのスレッド制御(joinとsynchronized)で取り上げたサンプルコードを、試しにシーケンス図でまとめてみます。
このように、シーケンス図を書くことで、各スレッドの連関をわかりやすく整理することができます。

・そのまま実行した場合

・①のコメントアウトを外した場合(join)

・②のコメントアウトを外した場合(synchronized)


UMLの図を書く時は、PlantUMLを使うと便利です。
PlantUMLは、テキストからUMLの図を生成することができるツールです。
UMLをテキストで書くことで、手軽に図を書けるようになりますし、Gitでの管理・差分比較もできるようになります。

下記のページにアクセスするだけで、すぐに使うことができます。
図の書き方(文法)についても説明されています。
https://plantuml.com/ja/

オンライン上で図を生成することが可能で、上記ページ中で試しに作ることができる他、「オンラインサーバ」のページにアクセスすることで大きな画面で作ることができるようになります。

セキュリティや作業効率等の問題でオンライン上で図を生成したくない場合は、ローカル上で図を生成することもできます。
ローカル上で図を生成する方法は、「クイックスタートガイド」に書いてあります。

以下、試しに、シーケンス図を書いてみたものです。
前述の「①のコメントアウトを外した場合(join)」のケースについて書いています。

【サンプルコード】

【生成結果】


いかがでしたでしょうか。

UMLの中では、シーケンス図はかなり使用頻度が高い図です。
今回紹介したケースのように、処理のタイミングを整理したい時に便利な図なので、書き方を覚えておくと良いでしょう。
その際にPlantUMLを使えば、図を書いたり管理したりする手間も少なくなると思います。

データレコードの種類を増やして拡張性を持たせる

以前に書いた「ヘッダレコード・データレコード・トレーラレコードとは」の続きです。


企業間でやりとりするファイルでよく見かけるフォーマットとして、レコードが「ヘッダレコード」「データレコード」「トレーラレコード」に分かれているフォーマットがあります。
簡単に言うと、それぞれのレコードの説明は以下のようになります。

【それぞれのレコードの説明】

・ヘッダレコード

ファイルの1レコード目のレコード。
一般的には、そのファイルが何日のデータなのかが記述される。

・データレコード

ファイルの中間レコード。
実際にやりとりするデータの中身が記述される。

・トレーラレコード

ファイルの最終レコード。
一般的には、そのファイルのデータレコード件数が記述される。


ここで、拡張性を確保するために、データレコードの種類を増やすという手段が有効になることがあります。
種類が異なるデータレコードをファイルに含める場合、データレコードのフォーマットを変えてしまうと、フォーマットが複雑になることで書き込み・読み込み処理が複雑になったり、フォーマット変更時の影響が全種類のデータレコードに出てしまったりします。
しかし、種類毎にデータレコードを用意することで、1つ1つのフォーマットが複雑になることを防いだり、フォーマット変更の影響が当該種類内のデータレコードに限定させることができます。

フォーマットと処理の例としては以下の通りです。
商品の種類毎にデータレコードの種類を変えることで、データ体系の違いを吸収している所がポイントです。
(1つのデータレコードにしてしまうと、1つのデータレコードに「食品商品コード」と「玩具商品コード」が含まれることになり、どちらを書き込むか・読みこむかの判断が必要になってしまいます。また、食品若しくは玩具にだけ新たな項目を追加する時に、追加が必要無い方の種類の商品の考慮も必要になってしまいます。)

【フォーマット例】

取扱商品ファイルを想定した例を記載します。
可変長のCSVファイルを想定します。
(固定長の場合も多いです。固定長の場合は、カンマ区切りではなくバイト数で区切ることになります。)

・ヘッダレコード

1項目目:ファイル区分(1がセットされる)
2項目目:ファイル作成日付(YYYYMMDD)

・食品データレコード

1項目目:ファイル区分(2がセットされる)
2項目目:食品商品コード(7桁の数値)
3項目目:商品名(全角文字)
4項目目:値段(数値)

・玩具データレコード

1項目目:ファイル区分(2がセットされる)
2項目目:玩具商品コード(6桁の数値)
3項目目:商品名(全角文字)
4項目目:値段(数値)

・トレーラレコード

1項目目:ファイル区分(9がセットされる)
2項目目:データレコードの件数(数値)

【ファイルのレコード例】

【ファイル受信時の処理例】

ヘッダレコードやトレーラレコードは、受信側のチェック処理に利用できます。
以下、ファイルを1レコード目から順番に読む場合の処理例について記載します。

・ファイル区分が1の時

1レコード目がファイル区分1でなければ異常終了。
(送信側が中間ファイル等誤ったファイルを送信することを想定)
バッチ日付と比較し一致しなければ異常終了。
(送信側が誤って過去ファイルを送信することを想定)

・ファイル区分が2の時

業務上必要な食品向けの処理を実行。

・ファイル区分が3の時

業務上必要な玩具向けの処理を実行。

・ファイル区分が9の時

最終レコードのファイル区分が9でなければ異常終了。
(ファイルを全件受信できていないことを想定)
件数がファイル区分2~3のレコード数と一致しなければ異常終了。
(ファイルを全件受信できていないことを想定)


いかがでしたでしょうか。

このテクニックは、レガシーなシステムでは良く使われるテクニックです。
レガシーなシステムの設計をする場合に、もしかしたら役に立つことがあるかもしれません。