DBサーバーの負荷分散
MySQLアクセスを負荷分散する ユーザーからのアクセス数が非常に多いWebサイトにおいて、MySQLのSLAVEサーバーを複数台並べて負荷分散させるということがよく行われています。ただ、Webアクセスの負荷分散は一般的なテーマなのでいろいろなところで語られているのに対し、DBアクセスの負荷分散というテーマは一般的でないのかあまり語られていないように感じます。 DBアクセスを負荷分散するにあたって一番荒っぽい方法は、Webサーバー上のプログラムの中でどのSLAVEサーバーに接続するかをランダムで決める方法です。ランダムと言っても長時間アクセスしているとほぼ接続先が均等化されるので、一見この方法でも問題ないように見えます。しかしこの方法だと、接続しに行こうとしたSLAVEサーバーが高負荷もしくはサービス停止中であっても構わず接続しに行ってしまうという問題があります。 このような問題を解決する
Tomcat Webアプリケーションマネージャを使ってみよう！
GUIによるWebアプリケーションの管理と配備 「第6回：TomcatにWebアプリケーションを配備する」では、WebアプリケーションのディレクトリやWARファイルをコピーしてコンテキスト設定ファイルを編集することで、Webアプリケーションの配備を行いました。 Tomcat Webアプリケーションマネージャ（以下、Webアプリケーションマネージャ）を用いると、このWebアプリケーションの配備や起動、終了、再起動、配備解除をWebブラウザからGUIで管理できます。そこで今回はWebアプリケーションマネージャを用いて、アプリケーションの管理と配備をしてみましょ う。 Webアプリケーションマネージャとは 前回紹介したTomcatにWebアプリケーションを追加する作業は、Webアプリケーションマネージャを用いると自動化できます。さらにWebア プリケーションマネージャを用いると「Webアプリケー
TomcatにWebアプリケーションを配備する
Tomcatの構造 前回まででTomcatのインストールが完了しました。今回はTomcatに新しいWebアプリケーションの配備を行います。Webアプリケーション配備の前に、Tomcatのディレクトリ構成を見てみましょう。 Tomcatのディレクトリ構成 今回利用しているTomcat 5.5のインストールディレクトリは以下のような構成になっています。Tomcatのそれぞれのディレクトリの役割は以下の通りです。
[ThinkIT] 第1回：企業戦略を支える技術としてのBPI (1/4)
ビジネス・プロセス・インテグレーション（BPI：Business Process Integration）とは、簡単にいってしまうとビジネスプロセスをシステム的に統合するための技術である。しかしBPIをこのように技術的側面からだけ捉えたのでは、本質的な意味は見えてこない。 BPIを柔軟なシステム基盤を作るためのサービス・オリエンテッド・アーキテクチャ（SOA：Service Oriented Architecture）の中の重要なコンポーネントと位置づけ、企業のある一時点における業務システムを実現するための技術としてだけで考えるのではなく、企業が存続するための企業戦略を支える技術として考えるべきである。 BPIを「複数システム間での処理を連携させて、プロセスとして統合することにより、ビジネス的に意味のある一連の作業の『End To End』での自動化を実現すること」と定義する。 具体例とし
前編でご紹介したBPIを実現するための要件と機能の一覧
コンポーネント化（ビジネスプロセス部分、データマッピング部分、ビジネスルール部分、ユーザ入力部分） （参照：http://www.thinkit.co.jp/cert/project/10/3/2.htm）
[ThinkIT] 第1回：BO定義とインターフェース定義 (1/4)
「企業戦略におけるビジネス・プロセス・インテグレーション」の連載では、ビジネス・プロセス・インテグレーション（BPI：Business Process Integration）と他の技術の違いやサービス・オリエンテッド・アーキテクチャ（SOA：Service Oriented Architecture）との関係などから、BPIの位置付けとBPIを実現するための要件と機能、それらを実現するメリットや難しさについて説明した。 特に重要な点は、BPIの機能を単なる柔軟な業務システムを作るためだけではなく、柔軟なシステム基盤を作るためのSOAの中の重要なコンポーネントと位置付け、企業が存続するための企業戦略を支える技術として考えるということであると結論付けた。 本連載では、「企業戦略におけるビジネス・プロセス・インテグレーション」の内容を踏まえて、それらを実装する方法を紹介する。 ここでは実践方法
[ThinkIT] 第2回：ビジネスフローの設計 (1/4)
「第1回：BO定義とインターフェース定義」ではBPIの具体的な実装例として、天然の原木一枚板を使ったダイニング・テーブルの販売を行っているO社のネット注文システムを取り上げた。ネット注文システムを構成する各システムの構成を整理し、それぞれのシステムのインターフェースとなり、成果物であるWSDLおよびXSDを作成する流れを説明した。 前回から引き続いて、今回もビジネスプロセスの実装について説明する。 ビジネスプロセスフローの設計では、ビジネスプロセスを実現するために個々のロジックやサービスをどのような順番で呼び出していくなど、処理のコントロールに関する仕様を決めていく。ビジネスプロセスの成果物はビジネスプロセスを定義するための標準言語であるWSBPELによって記述される。本連載では執筆時点（2005年12月）で最新版であるVersion 1.1に基づいて解説を行う。WSBPELについては「第
[ThinkIT] 第1回：テスト手法とテストツール (1/2)
日々の生活の中でコンピュータは欠かすことのできないものになっていますが、その一方で、金融機関のシステムダウンなど、コンピュータを動かすソフトウェアの不具合がもたらす社会的・経済的損失が問題となっています。そのため、ソフトウェアの不具合を可能な限り取り除き、品質を確保するための「テスト」の重要性は、今まで以上に高まっています。 しかし、無限の実行パターンを持つソフトウェアの完全なテストを実行するのは不可能です。よって、テストはできるだけ効果のあるやり方で、できるだけ効率的に実施する必要があります。本稿では、そのためのテスト手法とテストツールについて説明します。 ソフトウェアの設計に関してオブジェクト指向などの設計手法があるのと同様に、テストにもこれまで培われてきたさまざまなテスト手法が存在します。 そして、そのようなテスト手法について体系的に分類する試みが、ソフトウェアエンジニアリング基礎知
[ThinkIT] 第1回：テスト手法とテストツール (2/2)
動的テストは、プログラムを実際に実行して行うテストです。通常皆さんが単体試験・結合試験などといった工程で実施しているテストです。 テスト対象のプログラムの内部構造を基にすべての実行経路の動作を確認するテスト手法です。コードカバレッジ（実行網羅率）を確保するようにテストケースを作成することを基本とし、最終的に一度も実行・確認していないプログラムコード部分がないようにすることを目標とします。 テスト対象のプログラムの内部構造をまったく意識せずに、外見の正しさ（入出力仕様どおりの結果になるか）を確認するテスト手法です。テストデータの作成方法として、限界値分析や同値分割・エラー推測といった技法があります。 動的テストは、上記のような分類の他に、別の観点からの分類として、性能・負荷テスト、ユーザビリティ（使い易さ）テストなどのテストがあります。これらについても、実際に実行して行うテストなので、動的テ
[Think IT] 第4回：チケットとソースコードを連携せよ！ (1/3)
【バグ管理の作法】Trac徹底活用！ 第4回：チケットとソースコードを連携せよ！ 著者：masuidrive 公開日：2007/12/27（木） Tracの最大の利点はSubversionとの連携にあり さて、最終回の今回はTracのチケットとソースコードの連携を実際に試していく。 コードを書く開発者から見た場合、Tracの最大の利点は普段使い慣れたSubversionから、Tracを使うことができる点にある。開発者は自分の環境に新たなツールをインストールすることなく、Tracへ情報を送ることができる。 Tracの操作は通常Webから行うが、すべての操作をコマンドラインからでもできる。この機能とSubversionへコミット時に自動的にコマンドを呼び出すフックという機能を組み合わせることで、開発者がリポジトリへコミットするとTracを操作するという処理を自動化できるのである。 Subver
[ThinkIT] 第2回：Subversionによるバージョン管理（前編） (1/3)
今回は、Subversionによるバージョン管理方法とウノウでの導入事例について前編と後編にわけて紹介していきます。 Subversionとは、無償で利用できるバージョン管理システムです。現在もオープンソースで活発に開発が進んでおり、執筆時点の最新バージョンは1.4.2となります。バージョン管理システムとは、ソースコードや仕様書などを含むドキュメントなど、時間とともに内容が変化するファイルを管理するシステムの総称です。 Subversionと同じようなバージョン管理システムとしては、CVS（Concurrent Version System）が有名ですが、SubversionではこのCVSで使いにくかった点を改良した次世代バージョン管理システムというコンセプトで開発が続けらています。筆者が実際にどちらも利用してみた結論として、導入をおすすめするバージョン管理システムは、やはり「Subver
詳細設計書（前半）
前回までに表1の? 7「機能設計書」の基本設計ドキュメントとして、「表紙」「I/O関連図」「画面レイアウト」「帳票レイアウト」について紹介しました。今回からは、詳細設計に関するドキュメントについて順に説明していきます。 "機能"単位での設計書 機能設計書は、機能単位でドキュメントが作成されます。例えば、「プロスペクト登録画面」と「プロスペクト一覧画面」と「プロスペクト一覧表」という3つの機能があれば、3セットの機能設計書を作ることになります。ここで注意して欲しいのは、設計書の記述はあくまでもユーザのイメージする"機能"単位で、プログラミング単位の"プロシージャ"や"クラス"ではないということです。この"機能"という概念について、図1「プロスペクト登録画面」を例に説明しましょう。 図1を見ると、「プロスペクト登録画面」という機能は、画面、イベント、BL（ビジネスロジック）などのオブジェクトか
単体テスト仕様書＆報告書
客先からの注文書を受け、その内容を受注入力する 受注入力した内容は伝票に出力される。印刷される伝票は、注文請書と注文伝票の2枚で、注文請書は客先に提出され、注文伝票は営業事務でファイリングする 受注の際、在庫があれば在庫に、在庫がなければ発注残に引き当てる。在庫も発注残もない場合は、営業担当者に判断を仰ぎ、発注依頼にまわすことができる DUNGEONでは、このような業務要件を本連載の第1回で説明した「業務フロー」というドキュメントに記載します。全体を通した業務の流れ、部署ごとの業務の役割、業務に使う画面や帳票などの種類を業務フローに図示し、上記のような業務要件を説明欄に記載するのです。 総合テストでは、実運用に近い状態でシステムが有効に機能することを確認します。本番同様のデータを使い、要求分析で定めた業務の手順にそってシステムを使って業務をまわします。うまく運用がまわるか、不都合はないかと
結合テストと総合テスト
ソフトウェアの開発におけるテスト作業は、「テスト計画」「テスト設計」「テスト実施」「テスト管理」という4つのプロセスで構成されます（図1）。 テスト計画プロセスでは、テスト全体の指針や概要をまとめます。テストの目的、対象範囲、実施方法、テスト体制、テスト環境、スケジュール、合格基準など、テスト全般に関わる方針を「テスト計画書」にまとめ、ユーザを含むプロジェクトメンバー全員で方向性を共有します。 テスト設計プロセスでは、策定されたテスト計画に基づいて、実際のテスト作業内容を設計します。テストのシナリオやテスト内容、確認すべき項目などを「テスト仕様書」に具体的に定義します。 テスト実施者は、このテスト仕様書に基づいてテストを実施します。障害を発見した際は、障害番号を採番し、障害管理票に記載して残管理します。これらの障害が片づいて、テストが正常に行われた場合は「テスト報告書」で報告します。 弊社
[ThinkIT] 第1回：リッチクライアントとは (1/4)
2003年頃からIT関連の各種メディアで、リッチクライアントという言葉が頻繁に使われるようになった。その間、多くのベンダーから"リッチクライアント製品"なるものが提供され、徐々に導入事例も報告され始めている。 このように注目され始めたリッチクライアントであるが、その背景にはWebアプリケーションの普及とWebブラウザベースのクライアント環境の問題が挙げられる。詳細は後述するがインターネットの時代に入り、クライアント／サーバ型のシステムと比較した場合の開発コストや保守容易性の利点からWebブラウザとWebアプリケーションサーバで構成されるWebアプリケーションシステムへの移行が進んだ。 しかし、Webブラウザベースのクライアントは、クランアント／サーバ型のクライアントと比較した場合、必ずしも利用者にとって使いやすいものではなかった。極端に言えば、利用者の操作性／利便性を犠牲にした上でWebア
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://thinkit.co.jp/images/article/40/2/4022_zoom.gif
[ThinkIT] 第3回：基本設計書 (1/3)
基本設計書