サーバの最近のブログ記事

eラーニングの受講のピークは?

皆さん、こんにちは。ヒゲです。

からっからの天気が続く東京ですが、そのせいかどうかはわかりませんが、インフルエンザが流行ってます。しかも新型です。去年は大騒ぎしたのに、今年は新型でも「ふーん」で済まされちゃうのですが。

会社のスタッフも何名かかかってしまい、それぞれ一週間ほどお休みをいただいたり、取引先のご担当者もインフルエンザにかかってお休みになられているケースが出てきました。

社内や周りでインフルエンザがこれほど多く発生しているのは今年がはじめてかもしれません。
ただこれだけで「今年のインフルエンザの流行はすごい」と言うのは早計でしょう。
スタッフの人数が増えたり、お取引先様も増えているので、さまざまな人との接触の可能性が以前より増えていることも大きいように思います。

スタッフの人数がn人からm人増加すると、インフルエンザにかかる率が○%増加する
とかいう計算式も成り立ちそうです。今度寝る前に考えてみます(笑)

そんなこと考えるより、手洗いとうがい、そして少しでもおかしいなと思ったらマスクをかける、という自己防衛が有効的ですよね。そして予防接種も。私は今年も予防接種を受けております。おかげで今は(まだ)インフルエンザにかかっておりません。皆様もご注意ください。


さて、今回のお話は学習時間帯やピークについて。

eラーニングの多くは「いつでも、どこでも」ネットに接続して学習ができるようになっています。
業務の合間に手が空いたからちょっと勉強しようとか、
週末に時間が取れたからまとまって学習しようとか、
会社からこの時間に学習するように言われたので学習しようとか、
さまざまな理由からその時間に学習するわけです。

もちろん、いつ勉強していただいても困りはしないのですが、運営者からすると一点、考えなければならない問題があります。

それは、「一番多くの受講者が学習するのはいつか? そして何人が受講するか?」という問題です。

たとえば、千人が登録しているeラーニングと100人が登録しているeラーニングがあって、ただこれだけでeラーニングシステムやネットワークの規模が10倍違うか? と言われると、これだけでは決められないのです。

上記の例でいっても、千人登録されていても、実際に使うのはその中の半分ぐらいで、かつ、同時に10名ぐらいしか使わないという場合もあるでしょうし、
100人だけしか登録してないけれど、授業で全員が使うので、同時に100名が使うという場合もあります。

後者はよりネットワークやサーバ設備を増強しなければならないでしょう。
そう、登録人数だけではなんとも言えないのです。

そこで登場するのが「ピーク」という考え方。そのシステムで一番多くの人が受講するとき、どのくらいの人が利用するのか? というものです。

このピークの予測でサーバの規模やネットワークを決定します。これは費用にも大きく跳ね返ってきます。

では、「このピークはいつ訪れて、そしてどのくらいの数なのか?」

これはeラーニングを設計するときには必ず通る関門です。ここを間違えると、余計な投資をしたり、あるいは「受講できない!」というトラブルが続きます。

この大事な数字をどうやって算出すればいいでしょうか?

答えは一通りではなく、さまざまなケースに応じて検討をしています。
たとえば、ということで、いくつか例示します。



■ピークはいつ来るか?

まず、何にも制限や配慮をせずにeラーニングの受講をしたときですが、たとえば、開始日と期限を下記のように定めたとします。
開始/終了期限
「この日から受講できますよ」という開始日と「この日までに受講してください」という期限の間に受講期間があり、この期間中に受講者は学習するわけです。さて、あなたならいつ勉強しますか?

一般的な答えを先に言っちゃいますと、ほとんどのケースでは「夏休みの宿題」状態です。一ヶ月以上にもわたる夏休み、宿題もたんまり出ます。遊んでいたいけど宿題(夏休みの友?)もある/宿題もあるけど遊びたい・・・ このジレンマにとらわれ、結局あせって勉強するのは8月30日とか31日とか、ぎりぎりになってようやく本気で取り組むのではないでしょうか。
(『サザエさん』に出てくるカツオ君は毎回夏休みの宿題をぎりぎりに徹夜して家族総出でやるキャラクターですが、これはいささか大げさに表現されているかもしれませんが・・・) 

そういうわけでeラーニングでも、このような受講をすると・・・
受講期限ピーク
上記のように、期限ぎりぎりがピークになります。
特に企業内研修などではこの傾向は顕著です。

「人は結局ぎりぎりにならないと勉強をしない」といえるかもしれません。


■ピークの時間帯

何時ごろピークを迎えるのか?
これは事情によって大きく異なります。

一般的には深夜帯の21時~24時ごろがピークになるケースが多いです。

余談ですが、以前パソコン通信やインターネットのダイアルアップでよく使っていた「テレホーダイ」というサービスがあり、これは深夜23時~翌朝6時まで特定電話に定額で電話がかけられるというものでした。ただ音声通話に使うケースはほとんどなく、多くはインターネットやパソコン通信で利用されてました。そういうわけでインターネットやパソコン通信はこの時間帯(23時~)で多く利用していたので、その名残もあるのか? という説もあります。
まあ一般的には仕事を終えて食事をしたりお風呂に入ったりしてくつろぐ時間が夜遅め、ということなのかもしれません。

ただ、これは万能の考え方ではありません。
企業内で学習する場合には、時間を縛っている場合もあります。どうしても皆さんが同じ業務をしているので学習をする時間が皆さん似通るというケースです。企業内ではよく見られるケースです。
こういった場合は受講シーンを考えて、いつ学習が行われるか、ということを検討しなければなりません。

また、対象年齢によっても異なります。さすがに子供向けサービスでピークが23時に来るということはありませんし、自宅から利用するeラーニングサービスだと授業時間にアクセスが来ることはありません。

もうひとつ、曜日による変動もあります。ある特定のeラーニングの受講状況を曜日単位で見ると、曜日変動が結構大きいことに気づきます。そのeラーニングの特性によっても異なりますが、たとえば土日は意外と少なく週明けが多いとか、あるいはその逆で土曜日にピークを迎えるとか、さまざまです。
このあたりは受講者の特性を分析しないとなんとも言えないところではありますが。


■最大受講率

このピークのときにどのくらい受講するかという受講率(つまり、ピーク時の人数÷全体の人数)ですが、これも事情によって異なります。

全員の行動がある程度決まっている場合、たとえば学校の教室で全員がパソコンに向かって一斉に学習をするのであれば、ピーク時の人数はその利用しているパソコン台数でしょう。また、企業でも「お昼は全員学習するように!」というお達しが出ていたとすると、そのピーク時の人数は相当なものになるはずです。
また、一斉試験で全員がeラーニングに向かって試験をする場合にもピークの人数は膨大になります。

そういう極端な場合は算出しやすく、ちょっと考えれば答えを出すのは難しくありませんが、「どうぞご自由に受講してください」という場合にその率がどのくらいか? というのはちょっと頭を抱えちゃう問題です。

これ、経験則上ざっくり言っちゃいますと・・・ 
消費税の税率ぐらい見ておけば無難」です。

消費税率=昔の3%現在の5%程度

一般的にはこの程度(3%~5%)です。誤差は結構あって、1%を切るケースもありますが、特殊事情がない限り、この消費税率を大幅に上回ることはあまりありません。どんなに多く見ても特殊事情を除けば、まあ上限は10%ぐらいかなと思います。

※消費税率が引き上げられると、このトークが使えなくなるのが寂しいです(笑)


以上、ざっくりしたことを書きましたが、経験則上、ごく一般的なeラーニングのピークは

  • 期限間際の深夜にピークを迎える傾向がある。
  • そのときの受講率は3%~5%程度

ということが言えそうです。

もちろん例外もありますし、上記見ていったように事情によって大きく異なりますので、あくまで参考程度にしてください。


さて、これでピークの算出はわかった、これでサーバやネットワーク規模を決めようと次に進めそうですが、ここからは運用の工夫の話です。


このピークを計算すると、結構大きい数字になってしまう場合があります。
青天井の予算があればいいのでしょうが、たいていの場合は予算は限られてますので、こうして出たピークの数字をまともに受けて導入するのもいいかと思いますが、「運用回避」で乗り切ることが出来るケースもあります。

いくつか例を挙げてみます。


■グループ別受講時間帯振り分け

受講者を複数のグループに分け、それぞれ受講する曜日や時間帯を決めることによってピークを平準化する考え方です。

たとえば、
  • 地域 ・・・ 関東以東 / 関西以西 など、地域で分ける
  • 受講番号 ・・・ 受講番号が数字の場合、末尾の数字が偶数/奇数で分ける

などで、グループ化します。

そしてそれぞれのグループが学習する時期を決めるのです。

たとえば
  • 曜日 ・・・ グループAは月水金 / グループBは火木土
  • 時間帯 ・・・ グループAは午前 / グループBは午後

などと割り振っておけば、単純に計算して、グループ数だけ分散されるので、
グループを2つ作っておけばピークが1/2、3つ作っておけば1/3に軽減されます。


■受講期限調整

受講期限を全員一律同じにするのではなく、人によってずらすという方法です。
これは「ピーク時が受講期限直前にくる」というものを逆手にとったやり方です。

たとえば、同じ学習内容を受講する人をグループA、B、Cの3つに分けて受講期限をずらしたとすると、下記のようになります。
学習期間ずらし

こうすることにより、ピーク時(期限の直前)が平準化されるというわけです。



いずれの方法でも、大してお金をかけず、工夫でピークを平準化することができます。
内容によってこの方法が採れない場合もありますが、特に大規模で導入を検討される方は、この考え方をベースに運用設計いただいてもよろしいかと思います。


そして最後に、これは今回の話とは若干趣旨が変わりますが、たとえばと例を挙げた夏休みの宿題、8月30日、31日で詰め込んで学習して成果が出るか? というと疑問を感じます。

友達や親や兄弟が7月末とか8月の上旬あたりに「ねぇ、早く宿題やったほうがいいよ。少しずつでいいから毎日やろうよ」と言ってくれたら、8月末に苦しまなくて済んだだろうし、じっくり学習に取り組めて成果が出せたような気がしません?

eラーニングでも同じ。放置してピークを期限直前に持ってくるのではなく、進捗に併せて指導を行うことにより、できるだけピークを平準化して日々すこしずつ勉強してもらったほうが受講者のためにもなります。

ピークを平準化するための施策としてだけでなく、学習効果の高い学習を提供するためにも、この指導というのも組み入れることをお勧めします。

DKクラウド

皆さん、こんにちは。ヒゲです。

先日mixiの母校(高校)のコミュニティに衝撃的な投稿がありました。
私の出た高校は福岡のカトリックの男子校です。
男子校だからといって硬派というわけではなく、まあのんびりした感じの学校でした。私は唯一人の高校からの入学者で他は全員が中学からの持ち上がりなのですが、だからといってつまはじきされるわけでもなく、皆で和気藹々のんびりした環境でした。
私は高校に対する愛校心が強いというわけではないのですが、それでも出身校なので、もちろん愛着はあるし、在学中はいろいろお世話になったと感謝しています。

さて、そんな出身の男子校、近々共学になるとのこと。
おおおおおお。
そもそも男子校や女子校って、ニーズに特化しているともいえますが、マーケットの半分を放棄しているとも言えますし、少子化の今ではなかなかレベルを保って人数を集めるのは難しいのでしょう。
親しい友人の男子校も最近共学になったと聞いていたので、ひとつの流れなのかもしれません。

そして、学校名も変更になるとのこと。
今までは独自の名前だったのですが、同じイエズス会系列の大学(上智大学)の名前を冠するようになるようです。
これもブランド強化のためには致し方ないことかもしれません。

それにしても学校名が変わる、しかも共学になるというのは、結構な衝撃です。
時代の変化についていかないと経営が成り立たないのでしょうが、何か寂しい感じもします。

閑話休題。

さて、今回はサーバの話。

サーバの提供形態については以前こちらで説明しましたが、今回はその中でもクラウドの話。

クラウドとは? 前の書き込みから抜粋すると

------
これは、クラウドを行なう業者さんが大量のサーバ環境をストックしておき、その領域をみんなで共用しましょうというものです。
業者さんは大量に調達することで安く提供できるだけでなく、大勢で設備を共用するので、あまり使っていない資源は他の人が使うなど、サービスが伸び縮みするので、結果総投資額が少なくなり、コスト的に安く提供できるというものです。
------

というものです。

弊社でも、このクラウドの考え方を取り込んだインフラを整備して提供してます。
仮称「DKクラウド」と呼称しております。

従来、お客さんにサービス提供する際には、専用サーバを提供するか、1台のサーバに複数サービスを混在させるかの手法をとっておりましたが、仮想化技術が進んだこともあって最近では仮想環境で提供することも増えてます。1台のサーバの上に複数のOSや環境を動かすというものです。

サーバの形態としては、最近はブレードサーバを導入してます。
従来より省スペースに大量のサーバを詰め込むことができるので場所代が削減できますし、集中管理を行なうこともできます。
さらに、仮想化技術を使うことにより、1台のサーバをいくつものサービスで割ることができます。無駄なサーバを持つ必要がなくなりました。

DBサーバやWebサーバも1台構成ではなく、別のマシンの仮想環境同士で冗長構成をとっており、万が一1台のマシンが停止しても他方のマシンが稼動しているので障害にも強くなってますし、大規模のアクセスがある場合でも負荷分散して処理することが可能になってます。

それに加え、ディスク装置も仮想化しており、EVAという装置を導入しています。詳しくはこちらをごらんいただくとして、仮想化時代の大容量ストレージであるEVAを利用すると、ディスクを無駄なく使えますし、パフォーマンスも向上し、サービス停止も最低限にとどめられます。

さらに、電源の冗長構成、ネットワークの冗長構成をとり足回りを整備してます。

これらを活用したサーバ統合環境、それがDKクラウドです。

いろいろしちめんどくさいことを書いてきましたが、要するに
高付加にも強く障害にも強く、かつコストも抑えられる
ということと、
仕組みをいちいちお客さんが考えたり構築しなくてもメリットを享受できる
というのが大きなポイントだと思います。

アプリケーションの対応も必要ですが、弊社のKnowledgeClassroomKnowledgeDeliver5はこのクラウド環境で動かすことを前提に設計されておりますので、ご安心してお使いいただけます。

 
サービスを安定して運用してほしい
 
安価に提供したい
 
大規模にも耐える運用をしたい
 
サーバのことなんて考えたくない!

そういうニーズをお持ちの方は是非ご活用ください。
手前味噌にはりますが、DKクラウド、かなりオススメです。



ところで、来週から新オフィスへ移転です。
ばったばたしております。

サーバ環境の提供形態

皆さん、こんにちは。ヒゲです。(と、今回から名乗ってみます。詳しくは後述)

装いも新たに再スタートした『デジタル・ナレッジ eラーニング ラボ』ですが、
前回の投稿で早速うちの社長から投稿がありました。
今のところ、テクノロジー面や与太話は私が担当をし、
教育効果や教育に対する考え方については「はが」が担当することになるかと思います。

といっても、あまり厳密に線引きをしているわけではないので、クロスオーバーしたり、ぜんぜん違う話に脱線したりはありうると思いますが、blogという特性上、ご容赦ください。

その他にも担当が増える可能性がありますので、その際はまたご紹介を致します。

複数の人が書くと、わかんなくなる可能性があるので、私の書き込みの場合は今後「ヒゲ」とでも名乗っておきますんで、どうぞよろしくお願いします。

(ついでに、脱線が多いのがヒゲの特徴ですので、暖かい目で見守ってやってください)


さて、今回はサーバについて。


eラーニングのほとんどはサーバにアプリケーションやデータベースやコンテンツがあり、それをインターネットもしくはイントラネットなどを利用して各受講者環境に配信をしたり、受講結果を収集してサーバにデータとして蓄積したりします。

このサーバをどう誂えるか? というのは導入を進める上では必ず通るポイントです。

サーバって専門っぽいし、私には何のことかよくわからない・・・ 得体が知れない、怖い・・・

とおっしゃる方は多いと思いますが、難しく言ってるだけで要するに皆さんが使っているパソコンとさほど違うものではありません。ただ、その僅かな差のためにサーバはサーバで一般のパソコンとは違う進化をしています。

たとえて言うと、一般乗用車とスーパーカーの違いということでしょうか。見た目は同じようなものだけど、一般乗用車は万民が乗って快適に過ごせる車、スーパーカーは特殊技能を持ったドライバーがコンマ1秒でも速く走るためのもの。
走る・曲がる・止まるという基本的な機能や、エンジン・ステアリング、シャシー、ブレーキなどの構成パーツの種類は同じようなものですが、求めるニーズの違い(市街地を快適に走る/時速250km/hぐらいで速く走る)で、求められるスペックや価格、手法やパーツの構成がまるで違うのと似てます。

そんなしちめんどくさいことはさておき、じゃあeラーニングをやろうというときに、決めるポイントがいくつかあります。

まず、乱暴に言ってしまうと、まず、サーバ提供形態には

    • 自前で内部に持つ
    • 外部の他所に置く
という2つの選択肢があります。


自前で持つというのは、学校や企業の中のイントラネットにサーバを構築するというものです。
なにせイントラですので、特定の場合を除いて外部からの閲覧は出来ず、逆に言うとイントラに囲い込んでいるので、個人情報や教材内容が外部に漏れる恐れが比較的低い提供形態です。人事データベースと連携して情報連携しましょうというときにも、お隣に人事データベースがあったりするので構築は物理的には楽に出来ます。

機密情報を扱うeラーニング、特に企業研修ではこの形態をとることもあります。

ただ、サーバ管理の作業は情報システム部門など内部で行なう必要があるので、そこをきっちり自前で行なう必要があるということと、eラーニングにかかるトラフィックやポートなど、情報システム部門といろいろ調整する必要があるので、それなりに骨ではあります。

それに、内部からの受講には使えるけど、外部(外出先や自宅など)からの学習は、VPNなどのイントラに接続できる環境を構築するか、サーバがインターネットに接続されていないと困難、というのがあって、ここはバーターでどっちをとるかを決める必要があるということです。


そこで、外部に置くという発想が生まれてきます。外だしすれば外部からの閲覧は問題ありませんよね。
これにも様々なレベルがあります。代表的なものを書いてみます。

  1. 外部のデータセンターに場所を借りて、自前のサーバを購入し自前で保守
  2. 業者に委託し、専用サーバを設置してもらい、運用管理を委託
  3. 業者に委託し、共用サーバの一部領域を借り上げて、運用管理を委託

ざっくり言うと、こんなバリエーションでしょうか。


外部データセンタ+自前サーバ+自前保守は相当なスキルが求められますが、自前で好きなようにサーバ構築ができるので、まあやりたい放題、好きに出来ます。規模が大きくなったから負荷分散して複数台で運用だとか、カリカリにチューニングしようとか、間に業者が入って利益を持っていかれるのは面白くないんで自前で全部やっちゃうぞ、とかいう向きにはうってつけです。
自動車をキットから作っちゃってカスタマイズしちゃうような人ですね。

ただ、これ、結構大変ですし、サービス落ちたら? 機材壊れたら? などなど、考慮することがたくさんあるので、腕に覚えがあるとか、既にそういう設備を持って運用しているとか、そういう方ではないとオススメはできません。


業者委託+専用サーバ+運用委託は効果としては前者と似ていて、自分で使える領域がサーバ1台ごと丸々使えるので、負荷が高い場合や、やりたい放題したい場合にはこの選択肢はなかなか良いでしょう。これを「ハウジング」というケースもあります。
おまけにめんどくさいサーバ運用も業者でやってもらえるので「手ぶらでスキー」感覚(古っ!)です。
車をリースする感覚でしょうか。

中には、「他社のサービスと混ぜるのは会社の方針にそぐってないので専用サーバを選択せざるを得ない」という場合もあります。その場合はこの選択肢となります。

ただ、1台丸々借り上げるので、そんなに使わないのにコストがかかるなぁというケースはあります。
(週末にしか乗らないリースの車は金額があほらしい)

そこで、業者委託+共用サーバ+運用委託が生まれるわけです。自前でがしがし使わないけど、それなりに使うんで使う分の領域を確保して使わせてもらうという感じです。これを「ホスティング」と言ったりします。
無理やりイメージで言うとレンタカーを使う感覚でしょうか。

最近ではサーバ性能が向上したので、この形態でも充分な性能を発揮できる場合も増えてきてますし、各社から出ているサービスも価格が下がっているのでお得なスタイルだと思います。


さて、
これら、外部のサーバを利用する場合にも、サーバ領域だけを借りるケースと、アプリケーション込みでサービスを借りるケースがあります。

後者は「ASP」や「SaaS」などと言いますが、サーバ構築・運用だけでなく、導入アプリケーションの構築・運用まで手ぶらでやってくれるのでサービス内容がニーズにあっていれば安価に安定して手軽に利用できるスタイルです。
たとえていうと、タクシーみたいなものですかね。
車の構造や運転を知らなくても目的地を告げると勝手に送り届けてくれるという感じです。


さらにここ最近勢力を伸ばし、次のサーバ技術の本命といわれているのがクラウドです。

雑誌などで特集記事が頻繁に組まれていますので、ご存知の方も多いでしょう。
これは、クラウドを行なう業者さんが大量のサーバ環境をストックしておき、その領域をみんなで共用しましょうというものです。
業者さんは大量に調達することで安く提供できるだけでなく、大勢で設備を共用するので、あまり使っていない資源は他の人が使うなど、サービスが伸び縮みするので、結果総投資額が少なくなり、コスト的に安く提供できるというものです。
イメージでいうと乗り合いバス。
バスの運賃を払えば目的地に安く送ってもらえる。でも他にも乗客がいるしバス大きいけど共用だよ、という感覚です。

このクラウドの大本命はAmazon EC2というサービスです。
本のネット販売で有名なあのアマゾンが、こういうサーバのサービスもやっているのです。
リリースされた当時はサーバ業界に激震を与えました。
なにせサーバ環境がかなり安めに提供されてるし、使った分の費用だけ払えばいいという価格体系も、そういうニーズを持った人にはうってつけのサービスです。

今のところAmazon EC2はサーバがアメリカやヨーロッパにあるんで日本からの接続速度が遅かったり、安定性が他に比べて低かったりしますが、アジアにも進出してくる予定らしいですし、こういうネガティブな部分は徐々に消えてくるものと思われます。

弊社でもいくつかのサービスをこのAmazon EC2を利用して提供しています。
使った感じですが、主にネットワークに起因することですが(アメリカ=日本で通信を行なうので)もっさりしていることを除けば、まあそれなりに安くて快適に利用できていますし、お客さんからも特にクレームを言われたことはありません。
そもそも「このサーバは落ちる可能性が高い」と思って構築するので、知恵を出せば活用方法はいろいろあります。

また、Amazonに限らず、他社もこのクラウドに追随しているので、同じクラウドといっても様々な特徴が生じ、選択の幅が広がるのもメリットです。



以上のように、ひとことで「サーバ」と言われるもののパターンを羅列してみましたが、
「サーバ」にもいろいろあるなぁというのがお分かりいただけたかと思います。
車のたとえで違いを説明しましたが、うーんこれって分かりやすいのかどうか微妙だなぁとか思っちゃいましたが、私のつたない説明でもご理解いただけましたでしょうか?


サーバは黒子で、テクニカルなことだし、何をやっているかよくわからなかったりしますが、
内容を細かく理解いただく必要はなく、それでよいと思ってます。

ただ、eラーニングを導入する際には、これらメリット/デメリットを理解した上で
最適なサーバ環境をお選びいただだければと思います。

サーバメンテナンス終了/増設いつでもOK

みなさま、こんばんは。

11月も終盤を迎え、いよいよ冬の気配を感じるようになりましたね。
今朝は、ぶるぶる震えながら出勤したぐらいです。

 

さて、昨晩はサーバメンテナンスでした。今月は大きなメンテナンスが立て続くので、通常であれば月に1度で済ませるところを、2回に分けて実施してます。

今回はサーバの確認やパッチ適用などといった定常のメンテナンスに加えて、データセンタ側のメンテナンスも行いました。

ネットワーク機器を入れ替えたり、回線を引き回したりという作業ですが、無事に完了しました。

デジタル・ナレッジでは2箇所のデータセンターで運用しておりますが、今回メンテナンスを行ったデータセンターは主にブレードサーバを導入しております。今回のメンテナンスではブレードの電源やファンなどの機器も増強しております。

というわけで、足腰を強化しております。いつでも増設OKです。

皆様のご利用をお待ちしております。

 

ところで、弊社でサービス提供しているASPについて、より強化するための施策を検討中です。

これまでより、よりよいサービスを皆様に提供できるんじゃないかと検討中です。

こちらも近々情報をお届けしたいと思います。乞うご期待。

サーバメンテナンス終了

皆様、おはようございます。

今は朝の7時を過ぎたあたり、お日様が上ってきました。

 

今日はサーバのメンテナンスの日。

デジタル・ナレッジでは、最低でも月に1度のサーバメンテナンスを行っております。

各サーバの稼働状況を確認したりOSのパッチを適用したり普段はできない作業を行ったりと、様々な作業を行うのですが、なにせサーバを停止して行う作業のため、受講者にご迷惑のかからないよう、作業は深夜に行われます。

そういうわけなのでサーバチームは最低でも月に一度は深夜から早朝にかけての作業を行います。

ハードな作業ですが、これもサービスを守るために不可欠な作業です。

 

今回は、通常のメンテナンスだけでなく、Study.jp for Schoolのデータベースサーバを新しい別のサーバに入れ替えました。事前の準備や入れ替え後の確認などで、今回のメンテナンスはかなり大掛かりなものになりました。サーバチームだけでなく、アプリケーションの確認や運用上問題ないかを確認するため、パッケージチームと運用チームも今回のメンテには参加してます。

一通りメンテナンスは完了しました。無事に終了です。

今回のメンテナンスで、これまで以上に安定して快適なサービスをご利用いただけるかと思います。

 

ちなみに、来週25日も他のメンテナンスで深夜作業です。デジタル・ナレッジでは現在2箇所のデータセンタを利用してますが、もう片方のデータセンタのメンテナンスです。

というような感じで、サーバチームは文字通り日夜がんばってます。

このアーカイブについて

このページには、過去に書かれたブログ記事のうちサーバカテゴリに属しているものが含まれています。

前のカテゴリはコーヒーブレイクです。

次のカテゴリはセミナー/講演/展示会です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

ウェブページ

Powered by Movable Type 4.21-ja