自宅PCのUbuntu化
先日、いきなり使ってたMacがぶっ壊れた。
とは言っても3年ぐらい前に中古で同僚から売ってもらった、2008年？モデルのMacbookProだけど。（もう起動しないのでモデルも確認できん）
ある日（12月24日）の早朝4、5時までは起動してたけど、寝て起きてつけたら起動すらしなくなった。
非常にショックを受けて落ち込んでた日に、ベンチプレス100kgが挙がって若干救われた。
んで、今まで数年Macを使ってて慣れてたんで次はMacbookAirにでもしてみようかと思って、オークションサイトや、フリマサイトを徘徊して物色してた。
年末年始休暇に家の中を持ち運べるPCがないのは困ると思ってたけど、やっぱ衝動買いな感じが抜けなかったので、いろいろ考えてデスクトップ使おうと覚悟した時にひらめいた。
「昔使ってたWindowsのノートPCにLinux入れたらいいんじゃね？」って。
以前、使ってたノートPCが実家に規制中にCPU焼けて使えなくなって、即買いしたWindows7
のノートPCが残ってた。Windows8→10にアップグレードして、元に戻そうと思ったら戻らなくて、リカバリもCDじゃなくてHDDの領域にあったけど、OS自体が書き換わってて二度とリカバリできない感じになって放置してたヤツ。
以前の会社だと、MSOfficeをメインでつかってたかあら、たまに自宅で資料作成してた時にLinuxだとキツイなー。と思ってたけど、今の会社は対外だけぐらいでMSOffice使って社内ではGoogleDriveでもOKみたいな感じだったんでそこら辺の問題もなさそうだし。
ってことでUbuntu 16.04 LTSを導入。
久々にLinux。やっぱWindowsはどこにでもあるけど、SSHとかITインフラ系のソフトが初期状態で揃ってないのが面倒。ちょっとした手間なんだけど、意外と萎える。
最近触ってるAnsibleとか、Dockerとかもローカルで実行できそうだなと思ってやっぱMac or Linuxが良かった。
んで、インストールしたけど、無線LANが繋がんない。。。優先はいけるけど、せっかくのノートPCが無駄になってしまう。ってことでググりました。
Ubuntu日本語フォーラム / NetworkManager が無線LANを認識しない
そしたらなんのことはない。無線LANの機能がOFFられてただけ。ただ、意外と気づきにくい、Windowsの時は気にせずつながってたし。
まあ、毎度起動時にOFFになってるんで一手間増えたけど、いつまで持つかわかんないMacを中古で買うよりかはとりあえずいいかなーって感じ。
んで、今度は日本語入力できないんで、またググる。パッケージが不足してた模様。
次は、個人的には重要なアプリの「keepass」をインストールしたら、一部の文字が文字化け。
まあいいかなーと思ったけど、またググッて発見。
kokufu.blogspot.jp設定変更で対応可能。
これで、とりあえず問題なく使える環境が用意出来た。
一瞬、最新のMac買おうとも思ったりしたけど、無料でもここまで出来て、今のとこ数日間は特に問題感じてないんで、やっぱLinux最高。
仕事で使うOSもLinuxなんで偉大だなと。
まだ、ブラウジングぐらいしかしてないんで今後は開発系の作業するときに効率の上がるアプリを導入していこうと思う。
もう、日付変わって明日からは2017年。
また今後の事も考えなきゃいかんので、進歩ある一年にしていきたいです。
では。
ベンチプレス成果(目標達成)
もう2016年も残り数日って事で年始に立てたベンチプレス100kg挙げるって目標をギリギリ達成‼‼
先週の挑戦では少し挙げた所で止まって失敗して、残り日数も少ないしかなり焦ってたけど一つは目標達成した年にできて良かった。
色々あってユルくではあるけど中学ぐらいから目指してただけに嬉しい。
これも定期的に通いたくなるような楽しいジムがあったからこそ。
まだまだギリギリな感じなので来年はパワーアップ&ダイエットして体脂肪下げていこう。
ログ収集・分析基盤の検討
今の会社では、自社のWebシステムをBtoBで販売してて、そのサーバ・インフラ周りの面倒を見てるけど、プロダクト数が１０くらいあってサーバの台数も200台ぐらいになってきてる。
この台数を２人でプロダクト毎に担当分け。
プラットフォームは主にAWSを利用していて一部IDCフロンティアも利用している感じ。
そのIDCフロンティア側も自分が担当していて、サーバ台数が２５台ぐらい、CMSのシステムでWEBサーバ２０台、DBサーバ５台って感じ。
んで、WEBサーバ中でVirtualHostが60個ぐらい存在するんで、正味800サイトぐらい存在している計算。
その中でTVとかに公開されてちょっとアクセスが増えるとすぐにCPUが上がってくるんで、どのサイトが原因なのか確認してた。
でも、実際ログも60個ぐらいあるんでタイムスタンプが最新のログとか見て目星つける感じなので、あまり正確なもんでもなかったし、tailとかで内容見てるけどそもそもそのログじゃなかったときとか意味ないなー。とは思ってた。
そこで、EFK(ElasticSearch+Fluentd+Kibana)に代表される、ログの収集分析基盤を導入すれば傾向とか掴みやすいだろうと思ってちょっと検証してみた。
前にも試しで構築とかしてたけど、ElasticSearch辺りが面倒な印象だったけど、今はAWSのElasticSearch Serviceがあるんでクリック数回で立ち上げれる。（さすがAmazon様）
なので、実際はFluentdの辺りだけを頑張った感じ。
もちろんこの本も参考にしました。
まだ、正式に導入はできてなくて、検証の段階だけど、大量のVirtualhostがあった場合にも、アクセス先のホスト名とかもログに出してしまえばサーバ側でログを分割する必要がないんじゃないかな、って思う。
しかも、同じElasticSearchのインデックスに投げればサーバ全体での傾向や、複数サーバのログを合わせて分析してCMSシステム全体での傾向も可視化することができるってのはなんとなくわかってきた。
「なんとなく」ってのは、CMSのシステム自体にはまだ導入できていないので他のプロダクトのログを投入して試験的に分析しているかんじなので。。。。
あとは、今まではApacheLogViewerとかでグラフ化してたのが、ブラウザだけでリアルタイムにできるんでかなり調査、分析するなら便利。
サーバログインとか、コマンドとかわからない非エンジニアの人に対しても状況把握とかはしやすいだろうし、kibanaの使い方を覚えれば自分の希望する分析もできる。
今後クラウド化が進んでいくにつれて、AWS AutoScalingみたいにサーバ自体が永続的なものではなくなっているんで、ログみたいな「あまり使わないんだけど、すぐに捨てるわけにはいかない」データを外出しして活用できる仕組みないと運用系のエンジニアはキツくなっていくだろうな。
ただ、まだWEBサーバのログの活用方法まではちゃんとできてないんで、そこらへんのメリットを他のマネージャなどにアピールできないと本格導入ができないんだよなー。
Hadoopセミナー参加
先日、某巨人の会社で開かれた無料のハンズオンセミナーに参加した。
テーマは実務では経験の無いHadoop/Sparkについて。
今の会社は導入・検討の可能性があれば平日でも外部セミナーに参加させてくれるところはありがたい。
やっぱそういうとこで社員のモチベーションとか、学習意欲って変わると思う。
本題に戻って、今迄なんとなくHadoopって聞いたことあったし、調べたりもしてたんでどんな時に使うソフトウェアなのかってのもざっくり分かってたけど、実際に触れるってのが良かった。
まあ、前もネット記事見ながら立ち上げて、クエリ投げて結果返ってきたけど、んで何がすごいの？的な感じだったんで肌ではメリットを感じれていなかった（データ数が少なすぎるんで当然）
書籍も電子で買ってたけど、よーわからんって感じで見なくなってたし。
まあ、今回一番良かったのは、実際に使ってる人に対して自分のモヤモヤを質問出来たこと。
最近だとRedshiftみたいな列志向RDBとかも出てるしGoogleとかぐらいしか出番ないんじゃないのか？とか思ってたけど、結論としては『大規模データ集計はどっちも出来るけど、そこからの操作に得手不得手がある』って感じ。
当然ペタバイトとかになればRDBじゃどうにもならんだろうけど。
ざっくり書くとこんな感じ。
■RDB
SQLが使える（かなり重要）
トランザクションが使える
インデックス使って絞り込んだデータ抽出が得意
バッファプール使って同じ結果を高速化
クエリの結果が早い
めちゃくちゃデカいGroupByとかどうなんのかわからん
ロール管理、アクセス管理がしやすい
オプティイマイザが枯れている
■Hadoop
シーケンシャルアクセスの設計なので特定のデータ抽出が苦手
大規模データにもスケールアウトで対応できる
少ない件数だと結果が返ってくるのが遅い
基本的にはjavaじゃないとデータの操作ができない
ディスクへのデータの格納方法が冗長化前提
チューニングが難しい
こう書くと、意外とRDBの方が良いなって印象。
ただ、時代と共にデータも増えてきてRDBも色々頑張って来たけど、どうにもならんくなってHadoopが使われるようになって来た感じかな。（歴史的な背景は不明）
本当は使いたくないけど仕方ない的な。
ただ、使い易くするようにSQLライクにデータ操作が出来るようにしたHiveなんかが出て来たみたい。
javaは一切出来ない俺でもデータ操作が出来る（すごい）
あとは、HadoopはMap/Shuffle・Sort/Reduceって処理の際の中間結果をディスクに書き出すようでまあ、デカいデータであればやっぱり時間がかかるってことで、インメモリで処理して高速化するようにしたSparkも出来てかなり実用的になった模様。
そういや最近はよくSparkって聞く気がする。
機械学習みたいに大量なデータを高速に処理する時にはメモリ上でササッと処理するんだろう。
メモリも安くなって来たからこそ実現できた事なのかもしれない。
最後はHadoop周りの自社製品の説明とハンズオンをやって終了。セミナーの時間が押しまくってセミナールームの利用時間ギリギリに逃げるように退散。
だけど、Hadoopに対する理解も深まったし、手ブラで無料であれだけの事を教えてもらえたのはラッキーだった。
さすがはインターネットの巨人様。ありがとうございました。
もう一回Hadoopの本を読んで再挑戦して見よう。
https://www.amazon.co.jp/Hadoop徹底入門-第2版-オープンソース分散処理環境の構築-太田-一樹/dp/479812964X
ベンチプレス成果
１月頭にジムの人と一緒に「2016年内にベンチプレス100kgを達成」を目標にして少しづつ記録してきた。
もう師走ってことで残り時間もないのでそろそろあと一歩のとこまで行ってないとヤバ目。
１１月ぐらいに95kgに挑戦したら、他の人は挙がったけど俺はちょっと挙げたとこでそれ以上持ち上げれなくなって、失敗。
かなり焦ってそれから挑戦できなくなってたけど、ジム行った時にたまたまベンチプレスに挑戦することになったから、95kgにトライ。
ゆっくりだったけど、重さ的には余裕ある感じで挙がった。
追い込むつもりで2回挙げようとしたけど、バーに巻いてあるスポンジのマジックテープがシャツに引っ掛かって無理だったw
でもこれであと残り5kg。今年もあと２０日ぐらい。ジムもギリギリまではやらないから実質残り２週間。なんとか間に合いそうな気もする。
来年は年初から別の目標を立てているので気持ち良く年内に目標をクリアしたい！
ZABBIX ホストのテンプレート設定
今、会社ではWEBシステム監視にZABBIXを利用している。
前職でも利用していて、ちょっと面倒な部分もあるけど、細かい設定もできるし、まあまあ慣れているのですぐに馴染んだけど、監視の設定自体がごちゃごちゃしてたので、統一化や、自動登録、マクロ利用などしてプロダクト毎にイイ感じに修正して運用していた。
あるプロダクトで日常的にリソース監視の通知が来てて「もうそろそろこの設定見直したほうがイイんじゃないか。」と思って、既存の監視テンプレートを流用して、修正した新規の監視テンプレートを作って適用してた。
毎日通知が来てる監視のトリガー感度を下げたけど、なーんかまだ通知がくるなーと思ってはいたけどちょっと経過観察してた。
んで、ふと気づくと新しい設定でもトリガーが登録されてたけど見覚えのないトリガーがあった。しかもテンプレートに紐付いてない。
よくよく考えてみると新規のテンプレート適用前の設定が残ってる模様。
そういえば、監視データを捨てるのが勿体無いのでテンプレートの「リンクを解除」してたからっぽい。
何台か同じ設定を適用したサーバがあったんで、悩んだ結果、元々の監視ホストをリネーム（一時的にそんなホストねーよ！って言われる）して、そのホスト設定を複製して新しいテンプレートを設定したホストを登録。
そうすると要らないトリガーとかがない真っさらなホストで登録できた。
もちろん監視データはないんで、古いホスト設定は削除せずに無効化しておいて後で削除する予定。
ZABBIXの仕様なのかちゃんと調べてないけど、ちょっと注意が必要みたいだ。
お勉強会
昨日今日で自社（というかグループ会社間）で勉強会っぽいものを初めて開いてみた。
題材はAWS Summitで聴講したサーバレス・AWS Lambdaあたりの話。
なんでかっていうと仕事でいろいろ触っててもやっぱ飽きてくる感じはあったし、グループ会社でもおなじAWS使ってるのは知ってたんで同じビルのフロアで近いからなんかしら繋がりを作っておきたいなって思った。
そこで相互に刺激しあえればいいなーって感じで。
結果、それなりに刺激になったって言われる程度には反応があった。
ただ、自分でやってみてもいろいろ改善点がありそうなので残しておきたい。
まず、
- ストレスの無いネット回線。これは必須だと思う。スライド見せるのに都度都度フリーズすると無駄に長引くし、雑談とかダレてしまう。最初に確保するべし。
- 開催日は決めてから告知したほうがいいかも相手に合わせると以外とズルズル開催日が決まらなさそうな気がした。
- プロジェクタはあったほうが良い。これは普通の話。
- 大体の必要時間は伝えたほうが良さそう。みなさん仕事の途中だったのに時間食ってすいません….
- 最初に対象者を明確にしたほうが良い。こちらの用意した情報と、参加者に乖離があった時にどっちに合わせるか？ってのは以外と面倒な話。
- できればリモートデスクトップは利用しないほうが良い今回は、手元のPCからリモートのデスクトップに接続してスライドを表示してたけど、結局リモート側のマシンの問題で表示がうまくいかない可能性があるんで手元のPCで表示するのが良さそう。そういう意味ではslideshareみたいなWebサービスはすごい有効。ネットがあればどこでも表示できる。
- スライドは複数を跨がないほうが良さそう。元々、AWS Summitの発表資料を利用しようと思ってたけど、いろいろあって勉強会自体のスライドからSummitの発表資料に飛ばしたけど以外と時間が掛かった。
- 実演する時は時間かかる作業は動画にしておいたほうが良さそう。待ち時間や、待ってる間に別のことしてたら見せれない感じ。エラーで動かないってこともあり得る。
結局は伝える側、伝えられる側で別れる場合は、伝える側が準備をどこまでやるのか？なのかな～。
そ の点は寿司や、酒飲みながらぐらいユルい感じでやれればなんでも許してもらえるかもしれない。
まあ、でもここら辺を考えるキッカケになったし。
今回は主催する側の苦悩などもちょっとはわかったかもしれないな。
でもポジティブな感想をもらえるともっと頑張っていろいろ刺激し合いたいぜ！って思えるんで自分に取ってもイイ経験になったな。また次回もできるようになんか頑張って触ってみよう。
