リブショカ(図書館書架)β版

リブショカ(図書館書架)に関する情報発信

サーバ監視を考える

久しぶりに時間ができたので,気になったことを2日続けて書き残してく。

サーバ監視は,現役時代はほぼ自力だった。ベンダーがサーバの死活監視ツール

だけは仕込んでくれたが,サービスレベル。プロセスレベルはフィールドSEが現場でスクリプトを書くレベル。でもこれで十分だった。牧歌的な時代でもある。

 

さて,現在のデファクトでは,サービスは様々なツールを使って自動監視,自動運転が基本らしい。いろいろと記事を読むが,まだピンとこない。Zabbix は名前だけ聞いたことあり。だが使ってみたいとはあまり思わなかった。導入するならこちら。

Mackerel サーバ監視[実践]入門

Mackerel サーバ監視[実践]入門

 

はてなのサービスとのこと。開発・運用サーバはIDCFクラウドの予定であるが,追加料金で使える。これは便利そうだ。

だが実際は,どのようにサービス用の環境を設計するかによって死活監視も変わってくるはずなので,まずはDockerから始めなければならないのは分かっている。

最近,本業が落ち着いてきたので作業できる時間が 増えてきたが,昔のような集中力がなく,ソースにフォーカスできる時間があまりない。集中力がきれて,調べものを初めてしまったり,突然死活監視を考えてみたり。これも休日開発の楽しみと思って,あまりカリカリしないようにしている。

qiita.com

このあたりとか,

speakerdeck.com

このあたりで少し勉強。ちなみにZabbixは

 

Zabbix統合監視「実践」入門 ~障害通知、傾向分析、可視化による省力運用 (Software Design plusシリーズ)
 

 これで少し概要をつかんでみた。

 

またサービスもできていないのにサーバ監視でもないが,忘れないうちに。

 

 

 

Dockerを考える

 まだ開発中ではあるが,Dockerを調べ始めた。

Docker実戦活用ガイド

Docker実戦活用ガイド

 

 開発環境は,PCで基本VmwareUbuntuを仮想で起動して行っていた。しかし作業を継続していると,徐々に環境のずれやリソースの問題が気になるようになってきた。現役時代は,まだ仮想化技術も出始めで,Dockerはまだリリースされていない。

 

いろいろと記事を読みながら,Dockerのメリット・デメリットも大分理解できてきたので,手を動かしてみたいと思う。個人開発・サービスには常に環境とコストの問題が付きまとうが,サービスリリースの時にもDokcerを使って運用できれば,コスト圧縮にもつながるように思える。

ただし,ただDockerを使うだけではダメで,CoreOSやAtomic Hostのようなコンテナ専用OSの利用も含めて考えていく必要があるであろう。

 

このあたりも,併せて動かしていきたい。時間がないのが最大の課題であるが,新しい技術はやはり楽しいものだ。コンテナを中心にデプロイ関係や管理関係ももう少し調査・実践したいと思う。

 

 

grails3.2.Xのアプリケーションをjettyへdeploy

久しぶりの技術関係,かなり手間取ったので備忘録的メモ。

 

現在開発中のWebアプリはApache+TomcatからJettyへとコンテナを変更する予定である。

これまでJettyは未経験。実装するサーバがミニマムであることから,リソースを節約

できる点を評価してJettyを選択した。Jettyのインストール自体はBinaryをDownload

して適当なディレクトリに配置するだけなので,割愛。

 

Webアプリの基礎ができた段階で,grails prod warでDeploy用warファイルを作って

tomcat7で稼働を確認していたが,jettyにデプロイする前に現状のwarをTomcat7で試すことにした。

 まずはOracle8へバージョンアップ。これはJettyがJava8だったため。これが

問題の始まり。grailsにはopenJDK7を使っていたので,grailsもTomcat7もOracle8に

たことによって,開発環境とDeploy環境で大きさ差ができた。これによってtomcat7

へのDeployでエラーがでるようになる。この部分については,Grailsのドキュメントで

回避策が書いてあったので,対応を施す。具体的には,build.graidleを修正

2 Getting Started 3.3.0

 

これでtomcat7でのDeployができたので,次はJettyへ.しかし,Deployはうまくいった

ように見えるが,実際はWebアプリとしてではなく,単に静的コンテンツとして

認識されているようである。最初に疑ったのは,Web.xml。grails3からはweb.xml

作成しないようになったので,これが原因かと考えた。Jettyのドキュメントには,

web.xmlは必須となっていたので,さらにこれが原因かと思えたが,よく考えれば

grailsのドキュメントには,grailsから生成されるwarはほとんどのサーブレット

コンテナでDeployできるとなってるのだから,そこを疑うのは間違っている。このあたりのカンが鈍ってしまうのは,現役リタイアなのでしかたがないかと思う。

結局,原因は複数であった。

 

 1)grails3.2.0ではwarの生成時にバグがあり,grails3.2.1へ更新する必要があった。

 2)grails3.2.9へ更新したが(SDK),これだけではbuild.gradleは更新されないので,ダミーのプロジェクトを作って,そこからbuild.gradleをコピーして,必要部分を追記した。

 3)スタートアップ用の組み込みコンテナがtomcatだったので,これをjettyに変更した。(build.gradle)

//*** stop  tomcat 
//compile "org.springframework.boot:spring-boot-starter-tomcat"

//*** add jetty 
compile "org.springframework.boot:spring-boot-starter-jetty"

 

    4)logback.groovy実行用のjarが不足するので,build.gradleに追加

         runtime 'org.codehaus.groovy:groovy-all:2.4.10'

 

これでどうにかDeployできた。1)まで行きつくのが早かったが,その先でこまった。2)については,てっきりGrailsの更新によって自動的にbuild.gradleも更新されるのかと思い込んでしまったのがいけなかった。

jettyについてもメモ。じつはjettyがいちばん曲者だった。

jettyそのものは,/usr/local/jettyに配置したが,ドキュメントでは,jetty稼働は別のディレクトリで行えとなっている。そのために,jetty_homeを設定するようだ。

で,実際にjetty.homeを設定してユーザーディレクトリから起動したのだが,

Webアプリを認識しない。/usr/local/jetty/bin/jetty.shを/etc/init.d/jettyにコピーして

これを実行するとダメ,しかし,/usr/local/jetty/bin/jetty.shで起動するとちゃんとWebアプリを認識する。これがよくわからない。現在も調査中。設定ファイルは.jettyrcとして起動するユーザーのホームディレクトリに配置して,ちゃんと環境変数等も設定できているので,問題ないと思われる。配布バイナリにはいっているstart.iniもちゃんと実行環境にコピーしているが,なぜか/usr/init.d/jettyではうまくWebアプリを認識できない。ここの部分の切り分けができずに,grailsに原因を求めたことから,無駄に遠回りした。

 

久しぶりに開発関係の作業だった。うまくいかずにかなり四苦八苦したが,終わってみればやはり楽しかったと思い返す。もう少し,まとまった時間がとれるとよいのだが。

 

本業の都合もあり,なかなか進捗しないのが悩みの種である。

 

 

 

Amazonとカーリルと書誌情報

カーリルから以下のアナウンスがあった

サービスに関する重要なお知らせ – カーリルのブログ

 

これまでメインで使っていたAmazonの書誌DBからオープンな書誌DBへの移行を随時行っていくとのこと。当面は,Amazonアソシエイト契約の解除はないとのことだが,どこかで書誌DBのスイッチは避けられなかったと思う。先手を打って,

openBD | 書誌情報・書影を自由にを始めていたのは素晴らしい。前の記事にも書いたが,このような活動にはエールを送りたい,かつ微力でも力になれればと思う。

 

最近は本業が多忙のため,すっかり開発ペースが落ちてしまっているが,そろそろAmazonAPIに手を付けようとしていたところなので,実装を少し変更しようかと考えている。書誌情報を取得できるリソースを複数利用できるようにして,可変機能として実装するように仕様変更の予定。

 

さて,自由に利用できる書誌関連DBが動き始めるのは非常に素晴らしい。しかし一方で,本当にAmazon並みの情報量が確保できるかについては,懐疑的な部分もある。

 多くの人々が,Amazonが提供する情報量をデファクトとして認識しているように見えるが,これは何も書籍に特化したものではない。すべての商品について言えるのではないか。Amazonの情報量がデファクトとなっているのであれば,どこのサイトであれ,情報量が少なければ利用者は自ずとAmazonサイトへ移動して不足している情報を補おうとする。書籍でいえば,例えば書影,目次,コメントなど。多くの図書館目録検索ではこれらの情報は非常に少ない。それゆえ,Amazonで資料を探す→図書館検索で所蔵を確認する,の流れになることは多いであろうが,カーリルを使えば検索コストは大幅に省かれる。ゆえに,カーリルとAmazonの関係性の変化は,図書館とAmazonとの関係性の変化でもある。

 

 カーリルという素晴らしい仕組みを前にして,図書館の役割を再定義する必要はないのだろうか。図書館とAmazonは直接的には触れ合わない,お互いに向き合わない関係性なのだと思う。橋渡しとしてカーリルがある,そう考える図書館員も多いのではないか。多くの書店がAmazonとの生存競争に向き合う中,図書館はどこへ向かうのだろうか,興味は尽きない。だがきっと,すべて良い方向に向かっていくと信じている。

 

悪癖と反省と改善

例年恒例の春先のバタバタ中でも,小刻みにソースを書いていた。進捗はわずかであるが,開発を継続できているのでよしとしている。PGに費やせる時間はごくわずかなので,おのずとソースを眺めて,一行も書かずに,これまでのステップを復習することだけで終わる日も多々ある。

 そうやっていると自分の手のクセというか悪癖というかいろいろと見えてくる。20年以上大なり小なりの開発をやっている中で,現役時代は無意識に逃げていたであろうものだ。その一つは,デフォルト機能よりも自分が過去に書いたクラスや関数を多用してしまうこと。タイトな開発スケジュールだとどうしても稼働実績のある自作クラスに頼りがちだったことは否めない。引退した今であればこそでもある。

 domain class での処理が一例。本来であれば,domain classのmethodを使い,エラーをださせて処理すべきであるが,エラー処理を簡略化するためもあり,domain classを利用する前に,登録用の前処理をしてdomain classが想定されるエラー以外を吐き出さないようにしてしまっていた。だがこれは間違っている。特に自作クラスで処理していたのは,domain classと登録用データのbindの箇所。型変換やarrayなどの部分はアノテーション等を使わずに,登録前に自前のクラスで処理していた。ここは改善ポイント。

 このようにデフォルトよりも自作クラス優先は,フレームワークへのアプローチをミスしていることが根本的な問題点だと思う。本当に基礎的な部分でり,時間があればもう一度このあたりを勉強し直したいと思う。昔は何でも自分で作る=車輪の再作成的な文化が充満していた。これはこれで意義はあったので,そのクセが今になっても抜け切れていない。反省と改善。引退してしまった今だからこそわかる悪癖。それもこれまでのPGとしてのキャリアの一部であることは確かではある。

openBD 始動と基盤APIの選択

openBDのキックオフが先日あった。都合により参加できなかったがかなり熱があるものだったようだ。それは十分理解できる。現役時代に望んでいたサービスが鼓動を始めた。嬉しい限りだ。

openBD | 書誌情報・書影を自由に

 

さて,現在開発中のWebサービスで基盤データサービスとして候補に挙げていたのは,AmazonAPIとPortaである。どちらか一方ではなく,AmazonAPIをプライマリ,Portaをセカンダリというイメージだった。やはり書影データを使えること,アフェリエイトがあることが大きい。書籍に係る広告報酬はデータを登録してくれた利用者のためのもので,このサイトの運営維持費の捻出は,google系の広告を予定している。

さて,openBDであるが,期待は高まるが,調査しなければいけない部分もありそうだ。今回のサービスは,

 1)図書館員の業務補助ツール

 2)利用者サービス

の2つの目的としているが,どこまで取得したデータを加工して渡せるかについては,特に確認の必要があるだろう。また収録範囲や収録項目についても調査が必要だ。

 

キックオフでは,API開発を担当したカーリル社の方が,データ流通としてのXMLはダメ的な発言があったそうだが,これは同意。たしかに,XMLは素晴らしいしなんでもできる。一方,非エンジニアや図書館員にとっては,あまりにも難解すぎて利用する気すら起きなくなってしまっている。書誌データ構造は確かに複雑であるが,XMLで記述できるからといって際限なく複雑化するのではなく,2次利用しやすいという視点からある程度制限的な記述であることが望まれると考えていた。その点,JSONはいい制限加減なのである。データハンドリングもよい。

本題に戻るが,思想的な部分ではopenBD一択である。今回開発するWebサービスが少しでもopenBDの普及に役立てれば本望だ。だが一方でAmazonAPIで提供されるデータ量や質の問題を無視するわけにもいかない。どのデータソースを使っているかは,利用者にとってはどうでもよいことであろう。

もう少し,調査・検討してみるが,openBDをプライマリ,セカンダリをAmazonAPIとするのが第一か。また,調査してみるとカーリルAPIが素晴らしい。図書館として利用者登録してもらった場合には,なんとかカーリルAPIを使って,入力の手間を減らせればと思う。

なによりopenBDの登場により,さらに本と読者がつながることになるのは素晴らしい。図書館はこの流れに取り残されてはいけない。

 

openBDへの賛辞とエールを込めて。

 

2017年始動

すでに1月も半ばであるが,ようやく開発を再開できた。本業につられて開発がたびたび遅延するのは,いたしかたない。ブランクが長くて,頭の中に残しておいた工程やアイデアが消えてしまったので,もう一度やり直しである。

 

何事もない新たな1年の始まりであるが,今年は必ずこのサービスを公開させると決めている。本業とサブ,相乗効果を得られればベストだ。

 

休暇中は,これまで溜めていた技術系のブログを読んだり,サービス構想を考えたりして過ごした。現役時代はそんなことをできる余裕がなかった。

だが,引退したからこそ雑多なことから解放されて開発だけに集中できるのでこれは,良い環境ともいえる。

 

今年もないもないことが一番である一年であってほしいと切に思う。