新sanonosaシステム管理コラム集

2023年01月04日01:09

カテゴリ

(お知らせ)こちらのブログは閉鎖して元のココログに戻そうと思います

お知らせ。(2023/1/4)

・こちらのブログは閉鎖して、ココログのほうに統一することにしました。

・元々このブログは@niftyのココログで展開してました。
sanonosa　システム管理コラム集

・あるときココログに限界を感じてlivedoorブログに移転しようと考えてこちらを開設して少し移転してましたが、何年も放置したままでした。いつまでもこの状態は中途半端なので、こちらは閉鎖して元のココログに戻そうと思います。

どうぞよろしくお願いいたします。

2017年12月17日10:38

カテゴリ

「Amazon Web Services負荷試験入門」の書評

技術評論社より「Amazon Web Services負荷試験入門」を献本いただいていて、やっと一通り目を通すことができましたので僭越ながら書評させていただこうと思います。(遅くなって申し訳ありません;;)

Amazon Web Services負荷試験入門―クラウドの性能の引き出し方がわかる (Software Design plusシリーズ)

■総評

まずは総評です。実践的で実用的に役に立つ本だなあと感じました。私の中で良い本と思っているのは、実際に手を動かしたことがある人が自身の経験を基に、重要なことは懇切丁寧に、逆に重要でないことはさらっと触れるかもしくはばさっと切り捨てながら、著者のメッセージを読者が読みやすい形で最大限凝縮しているような本です。その意味では本書は著者のメッセージを十分感じますし、とても実用的な本だと感じました。

内容としては、負荷試験の失敗事例、負荷試験の一般的な話し、そしてAWS環境下でいろいろ負荷試験しながらサーバスペックを決めていく具体的な手順と、書いてあってほしい内容が一通り押さえられていました。

■失敗事例

1章に失敗事例が書いてあります。負荷テストをしないという事例や間違いだらけの（意味のない）負荷テストなどが書かれています。「あ～わかるわかる」と共感を覚える内容です。(苦笑)

■負荷試験の一般的な話し

3章から9章がそれにあたるかと思います。負荷試験で使われるツールの紹介、負荷試験の手順、負荷試験で得られたデータとその扱い方、そして負荷試験レポートの作成方法などが記されています。ここの内容は必ずしもAWSだけでなくて他のクラウドやオンプレ環境でも十分役に立つ内容です。

これまでなんとなく負荷試験してきた人が体系的に負荷試験の手順を学ぶのに良いと感じました。

■AWS環境下でいろいろ負荷試験しながらサーバスペックを決めていく具体的な手順

重複する部分もありますが7章から10章がそれにあたるかと思います。こういう結果が得られたからこの部分のサーバスペックを変更しましょう、といったことが書かれています。適当にサーバスペックを決める開発者がとても多い(個人的意見)ので、みんなこういう手順を経てサーバスペックを決めてくれたらいいのになあと感じる内容です。

以上、簡単ではありますが書評とさせていただきます。著者の皆さん、良書を書いていただきありがとうございます。また執筆お疲れさまでした!

2017年04月14日16:03

カテゴリ

Baculaの設定でハマったこと

オープンソースのバックアップソフト「Bacula」コミュニティ版の設定でハマッたところをメモ書きとして残しておきます。

・設定ファイルにはホスト名ではなくてIPで書く。例えばlocalhostではなくて127.0.0.1とか。どうしてもホスト名を使いたいときは/etc/hostsに書いてもOK。

・設定ファイルにPasswordを書くところが多いが、自分のパスワードの場合と、接続先のパスワードの場合が混在しているので気をつける。

・もしdirectorサーバとstorageサーバを兼ねるのであれば、bacula-dir.confのStorageディレクティブにあるAddressは127.0.0.1ではなくて自分のIPアドレスを書く。何故ならここで設定するIPアドレスはバックアップ対象サーバがStorage daemonサーバに接続するときのIPアドレスとなるから。

・bacula-dir.confの設定が終わったあと、必ずbconsole上で「label」コマンドを使ってVolumeを作ることを忘れないこと。これを忘れても画面上は特にエラーメッセージが出ないのでわかりづらい。・・・と思ったが、bacula-dir.confの設定中poolに「Label Format」を書いておくと、その名前で自動インクリメントされるようになるのでlabelコマンド実行は必ずしも必須ではないことが判明。

・bconsole上でTerminated Jobが残っているのが嫌なときは、director daemonサービスとstorage daemonサービスを止めた後に/var/spool/bacula/bacula-dir.9101.state と bacula-sd.9103.stateを削除すればよい。

・ストレージサーバ毎に1Jobしか走らないように設定する方法がなかなかわからず苦労した。結果的にbacula-dirのdirectory、storage,poolディレクティブにそれぞれ記載することでうまくいった。

・MySQLが認識しない問題。5.0.xのときは問題なかったのに、5.2.xからdefaultがPostgreSQLになっていた。

2016年08月12日20:07

カテゴリ: 雑記・コラム

「インフラエンジニアの教科書2 スキルアップに効く技術と知識」という本を書きました

2016年8月26日に「インフラエンジニアの教科書2 スキルアップに効く技術と知識」という本が出版されますので、ご紹介させていただければと存じます。

自分が若かりし頃に、こういった内容の本があったら良かったのになあ、という内容を詰め込みました。この本に書かれている内容はどれも日常業務に必要なものばかりなんですが、ネットもくまなく検索してみても、未だにまとまって整理されているものをほとんど見かけないんですよねえ。。。

インフラエンジニアの教科書2 スキルアップに効く技術と知識

■書評
書評いただきました。どうもありがとうございます。

■章立て

CHAPTER-01 プロトコル

CHAPTER-02 OS

CHAPTER-03 ネットワーク

CHAPTER-04 データベース

CHAPTER-05 WEBのサーバサイド開発言語

CHAPTER-06 共通鍵暗号方式と公開鍵暗号方式

CHAPTER-07 障害対策と障害対応

CHAPTER-08 よく知られたセキュリティ攻撃

CHAPTER-09 インターネットの運用と発展をつかさどる組織や団体

CHAPTER-10 RFCの読み方と作られ方

CHAPTER-11 世界規模のインターネットサービス運営

CHAPTER-12 インフラエンジニアとして目指す方向

■アピールポイント

・障害対応時に重要なOSの仕組みについて、ものすごく丁寧に書きました。OS上のプロセスがCPU、メモリ、ディスクなどのハードウェアとどのように連携しながら動作しているのかがわかるようになると思います。このあたりインフラ運用上すごく重要な基礎知識なんですが、最近はこういった内容が書かれた本をあまり見なくなりましたね。開発者の方にもこの章だけはインフラエンジニアだけでなくとも是非読んでいただきたいです。

・ネットワークに苦手意識を持っている人が多いので、最低限これだけ押さえておけば業務上困らないのではないか、という内容を書いてみました。

・データベースは、DBA視点ではなくてインフラエンジニア視点で書いてみました。ちょっと他の本とは書き方が違います。

・RFCの読み方を日本語で説明している本って意外とないので今回書いてみました。

・開発言語とWEBサーバ(Apache/Nginx/IISなど)の間をつなぐものについて、整理された情報があまりなくて今回整理してみました。この切り口で書かれた本は意外と他にない気がします。

・Javaの世界をインフラエンジニア視点で必要最小限に簡略化した上でわかりやすく説明しました。（開発者向けJava本だとインフラエンジニア視点で余分な情報がほとんどですから）

・SSL証明書の世界がどんどん変化していっていますが、昔勉強したきりで最新状況を押さえていない人も多いかとおもって、中間証明書、クロスルート証明書、EV証明書、ワイルドカード証明書などの内容を含めて書いてみました。

・インターネット関連組織であるISOC,IAB,IETFなどについても意外と日本では知られていないので今回書いてみました。

・WEB系企業に勤めるインフラエンジニアは概してWindowsに弱い人が多い(と思う)ので、普段あまり聞くことがないだろう内容(MFT、ファイル名文字コードの動的変化など)を書いてみました。

・世界規模のインターネットサービス運営に関わっている中で日々感じていることや実際に体験したことなどをまとめてみました。他であまり書かれない内容なので、面白く読んでいただけると思います。

■裏話

・前作「インフラエンジニアの教科書」が出版されるまで、インフラエンジニアというカテゴリーで出版された本がほとんどなかったと聞きます。結果的に前作がそれなりに多くの方に買っていただけたことで、結果的に各社からインフラエンジニアというカテゴリーの本が出されるようになった、らしいです。

・続編を書くことは全く考えてなかったですが、今回多くの読者の方や、各書店の店員さんからも名指しで続編の要望があったと聞きました。こういうことは珍しいらしく、結果的に引き受けることになりました。

・当初半年くらいで書き上げるつもりが、かなり丁寧に書いたために、1年近くかかりました。

・出版社のほうから「副題がないと売りにくいので副題つけてください」と言われて印刷所に入れるぎりぎりまで議論が続いてました。たしかに「インフラエンジニアの教科書2」だけだと前作との違いが購買を検討される方にとってもわかりづらいですよね。

■最後に

普段、新人インフラエンジニアを教育したり他部署から質問を受けたりしている中でいつも感じるのが、コンピュータの基本的な知識が不足しているので悩んでしまうのかな、ということです。そんな経験を踏まえつつ、他の本ではさらっと流されてしまう内容を丁寧に書いていたり、もしくは他の多くの本で書かれているような内容は省略したりとメリハリをつけながら、図を増やしたり文章を読みやすくしたりして極力理解してもらえるように丁寧に書きました。

これまで関わってきた本の中でもっとも愛着があり、また苦労した本でもあるので是非多くの方々に読んでいただければと思います。

どうぞよろしくお願いいたします。

2016年07月31日01:12

カテゴリ: サーバ・OS

ライブマイグレーションに失敗した話

VMwareサーバの老朽化に伴って新しい物理サーバを用意して次々とライブマイグレーションしていたとき、1VMのみライブマイグレーションに失敗するという症状に見舞われました。

よくあるライブマイグレーションに失敗する事例としては、マイグレーション先のハードウェアリソース不足、異なったCPUを使っている、実は移行先のハードウェアが壊れていた等いろいろあると思いますが、今回の場合はちょっと違いました。

結論から言うと、このVM（仮想サーバ）のみ割り当てCPUコア数が1となっていたからでした。

ライブマイグレーション実行後しばらくは順調に行ってましたが、しばらくするとVMに一切アクセスができなくなる、いわゆるフリーズ状態となってしまいました。そこでもう一度vmstatを回しながらライブマイグレーションを行うと、「r」の列が高い数値を見せて、その後固まりました。「r」列というのは実行中プロセス数と実行待ちプロセス数の総和ですが、この数値が高いということはCPUリソースが足りていないことを意味します。これを手掛かりに原因がわかったのでした。

2016年07月27日00:21

カテゴリ: 組織・スキルアップ

よい技術書の見つけ方

「最近よい技術書って少ないんだよねぇ」という話しが話題に上がりました。そこで今回はよい技術書の見つけ方を考えてみました。

【世間一般の良書と自分にとっての良書は一致しない】
まず重要なことなんですが、世間一般の良書と自分にとっての良書は一致しないです。読者の技術スキルや経験量がばらばらなので世間一般の良書は自身のレベルに合わない可能性が高いからです。技術的に正確で完璧であっても読者が読みこなせなければ意味がありません。

【買ってはいけない本は割とわかりやすい】
良い本というのは定義しにくいですが、悪い本というのは割と定義しやすいものです。例えば著者が技術をよくわかっていない本は買ってはいけないです。自分が知っていることを書いてある部分を読んでみて、正確でなさそうであれば買わない方が良いです。

本って数百ページも書くのは本当にしんどいです。その分量を全て正確な情報で埋め尽くすためには著者が技術の正確な理解と豊富な経験がないと不可能です。そんなわけで本の中身を見てみて少しでも雑な説明があったら著者の技術力は怪しいと思ったほうが良いかもしれません。

ただ、初心者向けの本はちょっと見極めが難しくて、著者は正確に理解していてあえて簡素に書いているのか、それとも著者が全然わかっていなくて結果的に簡素に書かれているのか。例えば「インターネットに接続するためには必ずデフォルトゲートウェイを設定しなければなりません」という説明を良しとしてよいのか、という話しです。

【よい技術書をどうやって見つけるか】
というわけでいよいよ本題です。こういうのはテクニックというよりは目利きが必要で、ある程度の量の本を読んでいると見えてくるものではあるのですが（これは美味いビールの選び方をビールを飲んだことがない人に説明しようとするシーンに似てますね。麦芽100%、天然水、自家製ホップで作ったビールが必ずしも美味しいわけではない！）、あえて法則を書こうとすると非常に難しいですね。

百発百中ではないのですが、著者の経験則を交えながら書いてある本は割と当たりが多いと感じています。経験したことを書いているので文面に著者の気持ちがこもっています。一方著者が経験したことがないことを本を書くために無理やり調べながら書いているような本だと気持ちを全然感じません。

この考え方で行くと、例えばOSの本だったら著者のプロフィールを見て、この人はOSが大好きなのかそうでないのか知るだけでも少なくとも良い本か悪い本か判断できるような気がします。

2016年07月25日22:26

カテゴリ: ソリューション・購買

購買の時間を少しでも短縮するために

サービスの成長に伴い購買額が大きくなるにつれて商談の頻度が増えてきます。例えば数千万円クラスの機器を買おうとすると、複数のベンダーから平均１０回くらい来訪いただくので、同時期に複数のものを買おうとすると購買専任の人がいないと毎日が商談になってしまいます。そんな中、少しでも商談の時間を短縮するためにいろいろ工夫したのでご紹介してみます。

【1．前もってお茶の準備をしておく】
お客様にお茶を出すのは常識ですが、自社からの参加者が自分ひとりだけだとお茶を準備するだけでも大変です。この問題に対して私はこのようにするようにしています。　

1. 前もって来訪者の人数を聞いておく。
2. 来訪５分前に人数分のお茶を入れて部屋に置いておく。
3. 部屋に入っていただいたら直ちにお茶を配る。

これだけで5分～10分は短縮できます。

【2．会議室の予約を短めにする】
商談を１時間刻みで行うことが多いですが、本当に重要な部分はそのうちの半分に満たないことが多いので、私はこのようにしています。

1. わざと会議室の予約を短めにする。(45分とか)
2. 来訪者に対して、この会議室は45分しか使えないと前もって宣言する。

これで15分の短縮です。

【3．要件定義資料を作り込んでおく】
商談の場ではこちらの要件について非常に長い時間ヒアリングを受けるのが普通です。これは思ったより時間がかかるので、私はこのようにしています。

①初回のコンタクト前にやりたいことを箇条書きしてメールで送っておく。
②最初の商談でこちらが疑問に思っているポイントだけを確認し、要件定義を作る。

こうすると2回目の商談から具体的な要件定義資料を元に話しが進むのでかなり商談が早く進みます。これで3時間以上の短縮になるのではないでしょうか。

【4．最終決定日を明確に伝える】
いつ最終的に決めますということを明らかにしておくと、そのタイミングで最終見積もりが出てきます。業者から見て最終決定日がわからないといつまでもバッファを持たせるのでいつまでも商談が終わりません。

【5．最終価格決定方法を業者に選んでもらう】
最終価格決定方法として以下の2つの方法があるかと思います。私はこのどちらがよいか業者に選んで決めてもらっています。

１．相見積もりを取っている業者の情報をお互いの業者に流しながら、どちらかがギブアップするまで見積もり書を交換する。
　→確実に安くなりますが、時間はかかるし決定した業者の利益がほとんどない状態になるので今後のお付き合いを考えると本当はあまりいい方法ではないです。

2.一発勝負で決める。
　→お互い後腐れがないし時間もかからないので個人的にはこちらのほうが好きです。

2016年07月14日00:20

カテゴリ: ネットワーク

LAN内にループがあるとどうなるか

LAN内にループがあってはいけないというのは常識中の常識ですが、専門スタッフが担当するデータセンターならいざしらず、社内ネットワークにおいてはいろいろな社員がいるのでそんな常識が遵守される保証はありません。

以前社内ネットワークが異常に重くなるというトラブルが発生し、調べたら会議室のＨＵＢが見事にループとなっていました。そのときのMRTGが運よく残っていたので公開してみます。こういう波形が出たらループを疑ってみてください。

(2016/7/14 追記： 2005年に書いた記事なので内容が古いです。現代はループ防止機能付きのスイッチなど様々なループ防止ソリューションがあるので昔ほどループを見かけなくなりました)

2016年06月23日01:20

カテゴリ: 雑記・コラム

「インフラエンジニアの教科書」という本を書きました

2013年11月に「インフラエンジニアの教科書」という本を出版させていただきました。おかげさまで大変ご好評いただき、2016年6月現在でも多くの本屋さんで平積みいただいております。

執筆時にこだわった点をアピールしてみます。

・「技術書なのに読みやすい」という路線を目指しました。さくさく読めると思います。

・文書だけだと読むのに疲れるので可能な限り図を入れました。

・起業してから現在に至るまで、個人的に悩んできたことの多くを盛り込みました。特に新たにインフラを立ち上げる場合役に立つと思います。例えば何か買いたいときどのようにベンダーや営業さんと付き合えばよいか、ルータはどれを買えばよいか、データセンターのラックにどこに何を設置すれば良いか等々、他の本ではあまり書かれていないような具体的なレベルのことがたくさん書いてあります。

・メモリには「ランク」という概念がありますが、拙著ではこのランクの意味をわかりやすく正確に説明している国内唯一の本ではないかと自負しています。ネットでくまなく探しましたが、日本語、英語共わかりやすく説明しているサイトが見つからなかったのでした。

・中小オープンソース系企業であまり使われないものについて一通り把握するのに便利です。

　　・Windowsライセンス体系

　　・VMwareライセンス体系

　　・ストレージの種類や技術全般

　　・エンタープライズ機器（電話回線接続してベンダーが障害検知する話しとか）

　　・SASディスク、FCディスク、Fusion-IO(ioDrive)の写真

　　・光ファイバ系の写真（ケーブル、LCコネクタ、SCコネクタ、GBIC、SFP)

　　・ネットワークファブリック構造

　　・データセンターの空調方式（排熱吸引方式、外気空調方式など）

など一通り網羅しています。

・一方、普通の用途に使われないと思うものはばっさり切り捨ててあります。例えばVMwareの製品体系は複雑ですが、本書ではvSphereとvCenterにしか触れてません。

・ライセンス購買のリファレンス的に使えるようにもしました。Win, RHEL, SQLSVR, Oracle, VMwareなどのライセンス体系と価格をわざわざ書いているのは、購買検討時にいちいちネットで検索しなくても済むので便利だからなのでした。ネットとは違い更新が効かない一般書で製品価格を入れるのはリスキーなので普通の本ではあまりやらないと思います。

では～。

2016年06月11日23:07

カテゴリ: 組織・スキルアップ

英語ができると技術習得が異様に速いと思った件

私の所属しているチームに新しい外国人メンバーが加わりました。彼は小学生の頃から英語で授業を受けてきただけあって英語はネイティブレベルです。ついでに書くと日本生活も長いので日本語もネイティブレベルです。

とはいえインフラエンジニアとしてのレベルはまだ発展途上なのでいろいろ教えながら業務にあたってもらっていますが、驚いたのは新しい技術の学び方です。