やーまんぶろぐ

気が向いた時にだけ書くブログ

RDSのread onlyのON/OFFをCLIで実行

AWS

こちらのAmazon RDS編 ~リードレプリカへの書き込み~ 記事を参考にread onlyのON/OFFをCLIで実行してみました。
recipe.kc-cloud.jp

パラメータグループのread_only のflagをONにすることで書き込みができなくなります。

read_only ON

$ aws rds modify-db-parameter-group --db-parameter-group-name XXXX --parameters 'ParameterName=read_only,ParameterValue=1,ApplyMethod=immediate'

反対にflagをOFFにすることで書き込みが可能になります。

read_only OFF

$ aws rds modify-db-parameter-group --db-parameter-group-name XXXX --parameters 'ParameterName=read_only,ParameterValue=0,ApplyMethod=immediate'

仮想環境(venv)の使い方 Python3 メモ

macで以下の環境で実行しました。

$ python3 -V
Python 3.5.1

Pythonの標準モジュールvenvを使うことで、プログラムごとに実行環境を分離できます。

$ python3 -m venv hoge
$ . hoge/bin/activate
(hoge) $ python -V
Python 3.5.1
(hoge) $ deactivate
$

バージョン番号を使わなくても、pythonコマンドで仮想環境に紐付けられたPythoランタイムを起動できます。

Pythonクローリング&スクレイピング -データ収集・解析のための実践開発ガイド- メモ

本

クローリング＆スクレイピングに興味があったので読んでみました。
サンプルページも多く、非常に参考になりました。

Pythonクローリング&スクレイピング -データ収集・解析のための実践開発ガイド-

Pythonクローリング&スクレイピング -データ収集・解析のための実践開発ガイド-

クローリング・スクレイピングとは何か

まずは説明。

  • クローリング
    • Webページのハイパーリンクをたどって次々にWebページをダウンロードする作業
  • スクレイピング
    • ダウンロードしたWebページから必要な情報を抜き出す作業

Pythonではじめるクローリング・スクレイピング

Webページを取得する、正規表現で情報を抜き出す、データベースに保存する、という3つの処理を行います。

ここではゴリゴリに実装しています。

強力なライブラリ

ライブラリのメモ。

データベースへの保存についても書かれています。

実用のためのメソッド

ここではよい設計について書かれています。
キャッシュを使って更新されたデータだけを取得する方法、クロール先が変化した場合のメール通知などが書かれています。

クローリング・スクレイピングの実践とデータの活用

ここではAPIに対応しているサービスの情報取得について書かれています。
APIで取得するとスクレイピングが不要になるので、けっきょくこれが一番実用的だと思いました。

他にもデータ可視化についても書かれています。

フレームワーク Scrapy

Webサイトのクローリング・スクレイピングをするなら、以下のことができるScrapyというフレームワークを使うのがよいみたいです。

  • Webページからのリンクの抽出
  • robots.txtの取得と拒否されているページのクロール防止
  • XMLサイトマップの取得とリンクの抽出
  • ドメインごと / IPアドレスごとのクロール時間間隔の調整
  • 複数のクロール先の平行処理
  • 重複するURLのクロール防止
  • エラー時の回数制限付きのリトライ
  • クローラーのデーモン化とジョブの管理

Elasticsearchによる全文検索についても書かれていました。

クローラーの継続的な運用・管理

AWSでの運用・管理方法が書かれています。EC2上のcronで動かすくらいなら、PythonだしLambdaでいいんじゃないかと思いました。

メールによる通知をSESもあるのでクラウド化できそうですね。

クラウド活用としては画像の保存先としてS3が紹介されていました。

Vagrantによる開発環境の構築

一般的なVagrantの話。

Pythonクローリング&スクレイピング -データ収集・解析のための実践開発ガイド-

Pythonクローリング&スクレイピング -データ収集・解析のための実践開発ガイド-

英語で読み解く ドラッカー『イノベーションと起業家精神』　メモ

本

この本の中では「変化をチャンスと捉えて、その変化を活かして新しい価値を生むこと」をイノベーション、「そのイノベーションという手法を使って、新しい価値を生む事業を立ち上げる人がアントレプレナー(起業家)」としています。

著書「イノベーションと起業家精神」を原文そのままで読むことで、ドラッカーの本当に伝えたかった意図に気づくことができる。というものです。

キーセンテンスがまとまっているので、非常に読みやすい作りになってました。

英語で読み解く ドラッカー『イノベーションと起業家精神』

英語で読み解く ドラッカー『イノベーションと起業家精神』

The Practice of Innovation イノベーションを起こす

起業家精神は理論として実践でき、体系的に学ぶことができるものだとしています。その理論とは、変化を当然かつ健全なものと見ることで、以下の7つの変化の種があります。

  • The unexpected 予期していなかった結果
  • The incongruity 不一致、ギャップ
    • 不一致、ギャップを適した形に変えることでイノベーションを起こす。「アクションはまずは小さく、シンプルに、フォーカスを利かせて」が鉄則。
  • Innovation based on process need プロセスニーズ
    • 明確な目的があるプロセスの中で生まれるニーズ。既に存在している仕事や作業の確立されたプロセスの中に生じるtask focused。
  • Changes in industry structure or market structure that catch everyone unawares 業界と市場構造の変化
    • 旧来型のビジネスを続けていくことは、ほぼ崩壊を保証するものであり、会社に滅亡を宣告するようなものだ。
  • Demographics(population changes) 人口動態
    • 近い将来に動く人口動態とそこから生まれる新たな機会は、誰でも予測することができる。
  • Changes in perception, mood, and meaning 認識の変化
    • 認識というのは目に見えないので変化を捉えるのが難しい。
  • New knowledge, both scientific and nonscientific 新しい知識
    • 「知」によるイノベーションが最強。完成したビジネスシステム、市場の絞り込みと集中、戦略的に優位なポジションで独占することが成功の鍵。

The Practice of Entrepreneurship 起業家的にマネジメントする

イノベーションを起こし、成功させ続けるための組織マネジメントについて書かれています。以下の6つにポイントを意識します。

  • policies 考え方
    • イノベーションを魅力的で、自分たちにもメリットがあるものだと捉えることが重要。破棄こそがイノベーションへの一歩で、変化をチャンスと捉えるようにマネジメントされなくてはならない。
  • practices 実施作
    • 問題に意識を奪われるよりも、チャンスに焦点を合わせること。最も価値のあるせいかとは、組織全体の考え方や風土が変化していくこと。
  • measurement 評価
  • structures 組織
    • 旧来の既存事業とは切り離して運営する。
  • staffing 人材
    • 必要なのは学ぼうとする姿勢。
  • dont's タブー
    • 自社の得意領域から外れたイノベーションのための努力は、成功する確立が極めて低い。

Entrepreneurial Strategies 起業家的に戦う~戦略~

具体的に4つの形の戦略が書かれています。

  • Fustest with the Mostest 最速、最強の戦略
    • その市場の中でリーダーの地位を獲得することが目的。最も優れているが、最もギャンブル性が高い。
  • Hit Them Where They Aint't 不意を突く戦略
    • 敵がきづかないうちに攻めよ。創造的模倣戦略は、ほぼ完成している製品をより完全なものにし、市場で適切な場所に位置づける。起業家的な柔道戦略は、ほぼ完成していたビジネスの種を事業化して成功を収める戦略。最もリスクが低く、成功しやすい。
  • Finding and occupying a specialized "ecological niche" ニッチ狙いの戦略
    • ニッチ戦略は他者からの脅威にさらされることが少ない。料金所戦略、専門技術戦略、特殊マーケット戦略がある。
  • Changing the economic characteristics of a product, a market, or an industry 製品、市場、産業の経済的価値を変える戦略
    • 顧客を創造する戦略。紅葉を創り出す戦略、値づけ戦略、顧客側の社会的・経済的事情に適合する戦略、顧客にとって真に価値あるものを提供する戦略がある。

英語で読み解く ドラッカー『イノベーションと起業家精神』

英語で読み解く ドラッカー『イノベーションと起業家精神』

DDoS関連のCloudWatchメトリクス

AWS

AWSのDDoS対策ですが、これから検討している方はまず実際に攻撃されてるかをCloudWatchで確認することをお勧めします。

DDoS関連のCloudWatchメトリクスは、AWS上でのDDoS対策資料のp55に一覧があるのでメモしておきます。
AWS Solutions Architect ブログ: [AWS Black Belt Online Seminar] DDoS 対策 資料及びQA公開

名前空間 メトリクス 説明
CloudFront Requests HTTP/Sリクエスト数
CloudFront TotalErrorRate 全リクエスト中HTTPステータスコード4xx/5xxの割合
Route53 HealthCheckStatus ヘルスチェックエンドポイントのステータス
ELB SurgeGueueLength ロードバランサーでバックエンド応答を待っているリクエスト数
ELB UnHealthyHostCount AZ中のunhealthyなインスタンス数
ELB RequestCount 登録インスタンスに転送した処理済みリクエスト数
ELB Latency ロードバランサーがリクエストを転送してから応答までの経過時間(秒
ELB BackendConnectionErrors 失敗したコネクション数
ELB SpilloverCount キュー飽和により拒否されたリクエスト数
AutoScaling GroupMAXSize オートスケーリンググループの最大サイズ
EC2 CPUUtilization CPU使用率
EC2 NetworkIn ネットワークインターフェースでの受信バイト数
DDoSProtection DDoSAttackBitsPerSecond DDoS攻撃の秒あたりビット数(0より大はDDoS攻撃検知)
DDoSProtection DDoSAttackRequestsPerSecond DDoS攻撃の秒あたりリクエスト数(0より大はDDoS攻撃検知)

DDoSProtectionsは「AWS Shield アドバンスド」のことです。

本番環境だけでなく、検証環境のリソースも確認しておきましょう。
自分の環境で確認してみたところ検証環境のELBのSurgeQueueLengthが単調増加していて、ログからアクセス元のIPを確認してみると外国からたくさん攻撃されてくることがわかりました。

私は検証環境だったので削除することで対応しましたが、本番環境の場合はWAFでIPをブロックするなどの検討が必要になります。

冒頭にも書きましたがまずは確認することをおすすめします。

How Google Works (ハウ・グーグル・ワークス) ―私たちの働き方とマネジメント メモ

本

Googleの働き方に対する考え方がわかる本です。

How Google Works (ハウ・グーグル・ワークス) ―私たちの働き方とマネジメント

How Google Works (ハウ・グーグル・ワークス) ―私たちの働き方とマネジメント

Googleのように優秀なエンジニアが成り立たないような考え方も多かった気もしましたが、新しいものを生み出すためには参考になる考え方がたくさんありました。

文化

スマートクリエイティブという言葉が頻繁に出て来ます。
自分の専門分野の深い知識を知性・ビジネス感覚やさまざまなクリエイティブな資質と組み合わせる人物のことです。

既存のビジネスではなく、新しいビジネスを生み出すためには、このスマートクリエイティブのような人材が求められているのだと感じました。

7つのルール(マネジャーは最低7人の直属の部下を持つこと) というのが印象的でした。
階層構造ではなく意思決定者を近くにおくことで組織をフラットに保つことが重要なようです。

マネージャーを少なくして、スマートクリエイティブ達が素早い意思決定を行えるようになっているのがGoogleの強みなんだと感じました。

戦略

市場調査はしない、技術的アイデアを中心に考える、顧客には聞かない。というように完全なプロダクト主義のようです。
個人的にはプロダクト主義こそ顧客に細かくぶつけながら開発していかないと市場と乖離したものが出て来てしまう気がするのですが、、

Dogfoodingな製品なら可能なのか？それともスマートクリエイティブならそれくらいできて当たり前なのか？

この部分はそのままは参考にできないかなと感じました。

人材

大事なのは「何を知っているか」ではなく、「これから何を学ぶか」というのが共感できました。環境変化が激しく、自分も1年間同じ働き方をしたことがないので、これからも「何を学ぶか」を大事にしていきたいと感じました。

人材を簡単にスケールさせる方法として、全社員が自分より優秀だと思う人を1人連れて来ればよい。というのが印象的でした。

新入社員のリクルーター活動をやったことがあるのですが、あれはある程度の人材をある程度の人数集める活動でしかないと感じました。
その活動の中で甲子園に同じ高校が毎年出られるのは、リクルーティングと教育がしっかりしているからというのを聞きました。

そのときはリクルーティングに力を入れる具体策は思いつかなかったですが、Googleのように全社員に人を集める権利持たせるというのも面白いと思いました。

意思決定

データに基づいて意思決定すると良いみたいです。

コミュニケーション

どんな情報でもオープンにする。

なんとなくですがGoogleはメール文化なのかな？と感じました。
個人的には入社してからずっとチャットでのコミュニケーションをとってきたので、メールが多いだけでがっかりしてしまいます。

場所を問わずリアルタイムにコミュニケーションを取れるチャットは便利ですね。

イノベーション

有名な20%ルールの話もでてきます。
個人的には20%で集まってきた人は、日が経つにつれて既存の80%の業務を優先して参加しなくなる傾向があると思っています。

新しいことをやるには、100%それに力をかけれる環境作りが大事だと思っています。
新しいことに力を入れているときは、余計な業務を振らないでほしい。

How Google Works (ハウ・グーグル・ワークス) ―私たちの働き方とマネジメント

How Google Works (ハウ・グーグル・ワークス) ―私たちの働き方とマネジメント

インシデント対応ボードゲームの参加メモ

参加レポート

社内で行われたインシデント対応ボードゲームに参加しました。

sp.trendmicro.co.jp

インシデント対応ボードゲームとは、実際にインシデントが発生したと仮定し、各プレイヤー同士がどのようにインシデント対応を行うべきか、それぞれの立場・視点で議論するというものです。

私のグループは以下の4つの役割になりきって実施しました。

  • CIO
  • システム管理者
  • セキュリティ担当者
  • 広報担当者

私はセキュリティ担当者でした。

ゲームを進める上で、前提を明確にしないと判断できない部分が多々あり、認識をすり合わせながら進めるのが難しいと感じました。

反対にインシデント対応の意志決定をするためには、いくつか情報が必要というのが気づきになります。

例えば、自社のトップページ画像が改ざんされたときに、前提によってインシデント対応が変わってしまいます。

現在改ざんの影響がわかっていない、社内にセキュリティのことがわかるエンジニアがいない、外部ベンダーを呼ぶ費用はこれくらい、停止したときの被害がこれくらいなどを決めておいて初めて意思決定できて、議論することが可能になります。

実際にインシデントが起きたときには余裕ないと思うので、
普段からシミュレーションしておくことを心掛けたいと思いました。