GoogleスプレッドシートからAWSを操作する
最近、TerraformやCloudFormationみたいに、JSONや独自DSLなどでかっこよくAWSを管理するツールがいろいろ出てきてます。 こういうツールは便利そうだなとは思うんですが、なんかふと、ユーザがホントに求めているものはコレなんだろうか？と思いました。 なんだかんだ言って、一番多く使われているサーバ管理ツールは『Excelサーバ一覧』なのではｗ？ じゃあExcelで同じようなことが出来ればそれが一番いいのでは？と。 というわけで、Excelは手元になくてキツイので、今回はGoogleスプレッドシートでAWSのサーバ構成管理をやってみました。 使い方 事前準備 サンプルのスプレッドシートをコピーする 『ツール』 -> 『スクリプトエディタ』 -> config.gsを編集 AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEYにAWSのアクセスキーを
インフラコストを削減する その1 - mikedaの日記
過去2回ほど、20%~30%程度のサーバ削減をやったことがあって、 その時のメモが出てきたので、考え方とかやったことをザックリまとめてみる。 まず例えば、不要なサーバを削減してインフラコストを月額10万円減らしたらどうなるか。 これは運用コストも解約リスクも無い、恒久的な利益になる。 裏返すと以前は恒久的な損失が発生していたということなんだけど、情報をまとめないとだれも気づかない。 なのでどこまでやるかは状況次第だけど、情報をまとめることは最低限必須だと思う。 ということで、『効率化する』、『安く買う』についてはまた次回にして、 今回は『情報をまとめる』、『ポリシーを決める』、『適切なサーバ台数を維持する』ことについて。 基本的にオンプレ環境を前提として考えます。 情報をまとめる まずは最初に言ったように、必要な情報をまとめる。 そしてだれでも見れるようにする。 これをしないと自分が思いつ
歳は気にするな。という自戒 - mikedaの日記
自分はLinuxは社会人になった26歳(新卒研修中に27歳になってたけど）から、WEB系技術は最初の転職の29歳から、と全体的にスタートが遅かった。 ※ちなみにプログラムは大学院の24歳から。CとC++とVBを少々。 なのでずっと、歳相応の能力がない点についてそれを言い訳的に使うことが多かったし、 個人に関する何かの決断について、もうけっこういい歳だしなぁみたいなことを考えることも多かった。 ※この業界はすんごく若くて優秀なやつがいっぱいいるからね！ まぁでも、 CAのoranieさんは26歳までアパレル店員だったし、 ペパボだと四天王の黒田さんは30歳まで郵便局員で、 技術責任者のあんちぽさんは32歳まで役場職員だった。 うろ覚えだけど。 少なくともWEB系のエンジニアとしてなら何をするにせよ、ビジネス的な成果を出すために最低限必要なスキルを身につけることに関して、そんなに長大な時間を要
フォロワーのブログのはてブ数を調べてみた - mikedaの日記
最近久しぶりにまた個人ブログを書き始めたんですが、 なんとなく気になって、Twitterでフォローしてる人達のブログの総はてブ数を調べてみました。 31761 元RX-7乗りの適当な日々 @namikawa 20355 delirious thoughts @kentaro 19416 blog.nomadscafe.jp @kazeburo 14450 (ひ)メモ @hirose31 13739 As a Futurist… @riywo 13684 たごもりすメモ @tagomoris 12067 昼メシ物語 @mirakui 10943 (ﾟ∀ﾟ)o彡 sasata299's blog @sasata299 10235 Glide Note - グライドノート @glidenote 9611 すぎゃーんメモ @sugyan 8340 酒日記 はてな支店 @sfujiwara 7794
検証中のtd-agent（fluentd）の設定とか負荷とか - mikedaの日記
せっかくなのでアクセスログ関連のところだけ抜き出してみます。 構成 概要 Fluentdを使ってWEBサーバ（APPサーバ）のアクセスログを集約サーバに集約、いくつかの処理をやってます。 要するにこの3つです。 まとめてファイルに保存する（とりあえずやってみてるだけ） TreasureDataプラットフォームにデータを送信して集計可能にする Zabbixでサービスの稼働状況を可視化する TreasureDataプラットフォームに関しては前の記事で書いたように、簡単な管理画面を作って集計テストをしています。自社フレームワーク用のライブラリも作成するつもりです。 Zabbixを使った可視化はこんな感じです。 プラグインの構成図 td-agentはサーバごとに1プロセス、できる限りシンプルでFluentdっぽい使い方を心がけてます。 負荷 2億/dayくらいのログを突っ込んでみたところ、集約サー
Treasure Dataの解析プラットフォームを使ってみた - mikedaの日記
ログの解析は日時でscpでかき集めてバッチ集計してるんだけど リアルタイムで集計したい もっと柔軟に集計したい という人は多いんじゃないでしょうか。 リアルタイム収集はFluentdを使えばいけそうですが、集計部分を柔軟にというとどうだろう。 CookpadやAmebaはHiveを使ってるとの情報がある。 『Hive on AWS @ COOKPAD』 『Amebaのログ解析基盤』 （どっちも古い。HiveはHadoop上でSQL（っぽく）ログ解析するためのプロダクトです） 「面白そうだなー。でもHadoopよくわからん、というかサーバいっぱいいりそうだから承認通すのめんどくさい(´・ω・｀)」 とか思ってたらSoftwareDesignの最新号にこんな記事が。 Cookpadの人 「Treasure Dataは...ログ解析用の商用プラットフォームを提供しています。 Fluentd経由で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
