kakakakakku blog

Weekly Tech Blog: Keep on Learning!

Curator 3 で Amazon Elasticsearch Service を扱う

最近 Amazon Elasticsearch Service の記事をよく書いてる気がするw

開発用のログ基盤ではあるけど,実際に導入は完了していて,既に運用している.今回はインデックスを Curator でハウスキーピングできるようにした話を書いておく.基本的には Elasticsearch と同じなんだけど,一部 Amazon Elasticsearch Service 特有の課題があった.

github.com

Curator Version

まず Curator にはメジャーバージョンが2個あって,Curator 3 と Curator 4 で大きく実装も変わっている.Elasticsearch と Curator の対応表は GitHub に載っていて,以下の通り.

Version ES 1.x ES 2.x ES 5.x
3 yes yes no
4 no yes yes

Amazon Elasticsearch Service でサポートされている Elasticsearch のバージョンは 1.5 と 2.3 だから,Curator 3 なら両方のバージョンに対応していて,Elasticsearch 2.3 なら Curator 4 も使えそうに見えるが,実は違う.Curator 4 では /_cluster/state/metadata から情報を収集しているが,Amazon Elasticsearch Service はこの /_cluster/state/metadata に対するリクエストを許可していない.

よって,現時点では Amazon Elasticsearch Service を使う場合は Curator 3 一択となる.

$ curl xxx.ap-northeast-1.es.amazonaws.com/_cluster/state/metadata
{"Message":"Your request: '/_cluster/state/metadata' is not allowed."}%

実際に「Curator 4 じゃ動かないよ!」的な Issue が多く出ているけど,基本的には Amazon Elasticsearch Service の仕様だから Curator として正式にサポートしない方針のように理解した.

github.com

github.com

pip で Curator 3 に固定する

現在の最新は 3.5.1!

$ pip install elasticsearch-curator==3.5.1

ポートを指定する

Curator はデフォルトだと 9200 ポートに接続する.Amazon Elasticsearch Service の場合は 80 ポートなので --port 80 と忘れずに指定する.

/usr/bin/curator --host xxx.ap-northeast-1.es.amazonaws.com --port 80 delete indices --prefix yyy --older-than 90 --time-unit days --timestring %Y.%m.%d

スケジューリング

コマンドをラップしたシェルを用意して Jenkins から日次で実行している.Amazon Elasticsearch Service は日次でスナップショットを取るため,余裕を持ってその後にスケジューリングしている.

関連記事

closebloom など運用 Tips を参考にさせてもらった.

qiita.com

Amazon Elasticsearch Service 関連記事

kakakakakku.hatenablog.com

kakakakakku.hatenablog.com

Coursera で "Cloud Computing Concepts, Part 1" Week 2 を受講した

Coursera

Coursera でイリノイ大学の講義 "Cloud Computing Concepts, Part 1" を受講してる!

Week 2 に関して個人的な勉強メモをまとめた.

Week 2 : 期間

  • 2016/09/05 - 2016/09/11

Week 2 : アジェンダ

  • Week 2: Gossip, Membership, and Grids
    • Overview
    • Lesson 1: Gossip
    • Lesson 2: Membership
    • Lesson 3: Grids
    • Interview
    • Homework

Lesson 1: Gossip

最初はマルチキャストの課題とは何か?から学んだ.マルチキャストとは,ユニキャストとブロードキャストの中間とも言える通信手法で,特定のノードグループに対してメッセージを送信する.前提としてノードはクラッシュするし,パケットはロストすると考える.またノード数が増えるとオーバーヘッドも増えるため,対障害性とスケーラビリティがマルチキャストの課題となる.

マルチキャストの実装には以下のアプローチがあり,それぞれにメリデメがある.最も優れているのは,ゴシッププロトコル(疫学的プロトコル : Epidemic Protocol と呼ぶこともある)とのこと.

  • Centralized(中央集約型)
    • 最もシンプルな実装で,単純なループ処理で実現できる
    • 対障害性に課題があり,送信の途中でエラーになると,再送ができなくなる
    • 計算量としては O(N) になる
  • Tree-based(木構造型)
    • IP マルチキャストのように,ルータやスイッチごとに木構造に分散させる
    • 計算量としては O(log(N)) になり,中央集約型と比較すると早くメッセージを届けられる
    • 木構造のセットアップとメンテナンスコストが課題になる
    • もしノードがクラッシュした場合は,別のノード内のグループに移動させる必要がある
  • Gossip Protocol(ゴシッププロトコル)
    • 特徴
      • 定期的(5秒間隔など)にランダムにターゲットノードを選択して UDP でゴシップメッセージを送信する
      • 受信側も同様に定期的にゴシップメッセージを送信する(当然,同じメッセージを別のノードから受けることもある)
      • 受信することを感染する (infected) と表現する
      • 全てのノードは独立している
      • 噂話があっという間に広まるのと同じように,一度送信したメッセージの広がりを把握することは難しくなる
    • 種類
      • Push ゴシップ
        • O(log(N))
      • Pull ゴシップ
        • ターゲットノードに「最新のゴシップメッセージを持ってる?」と問い合わせる
        • O(log(log(N))) で拡散の速度は Push より Pull の方が圧倒的に高速
      • Push-Pull ゴシップ
        • Pull で問い合わせて,結果を Push で送信する

ゴシッププロトコルで実装されたサービス(ミドルウェア)も紹介されていた.

  • NNTP
  • Cassandra
  • EC2 and S3(ただし,公式には発表はされてなく噂として)

Lesson 2: Membership

データセンターでサーバは故障する."Failures are the norm in datacenters." という表現だった.サーバが故障する頻度を認識する話で,MTTF の計算問題が出てきた.例えば,12ヶ月で故障するサーバが120台あった場合,MTTF は1ヶ月だし,12000台あった場合,MTTF は7.2時間となる.

次に,サーバの故障をどう検知するか?という話で,1000人の従業員を雇って常にモニタリングするよりも,自動で故障を検知するシステムを用意した方が正しく,メンバーシッププロトコルの解説があった.

メンバーシッププロトコルはメンバーシップリストを更新するが,更新手法として3種類ある.2個目の "Almost complete list" がゴシップスタイルで,今回のフォーカスとなる.

  • Complete list all the time (strongly consistent)
  • Almost complete list (weakly consistent)
  • Partial random list

メンバーシップには重要なプロトコルが2個ある.イメージとしては,プロセス(pi) がプロセス(pj) の故障を検知した場合,その情報をグループの他のプロセスに拡散することで,結果整合的にリストを更新する.

  • Failure Detector(故障検知)
  • Dissemination(拡散)

故障検知には以下の特徴がある.

  • Completeness(完全性) : 全ての故障を検知できること
  • Accuracy(精度) : 誤検知をしないこと
  • Speed(速度) : 故障を検知するまでの時間
  • Scale(スケール) : メンバー数に依存しないこと

Completeness と Accuracy を同時に満たすことは不可能で,通常は Completeness を保証し,Accuracy は100%でない場合がある.ただし,誤検知が起きても,確認してグループに戻すことで,大きなオーバーヘッドも無く,回避することができる.

そして故障検知のためのハートビートにも計4種類の手法がある.

  • Centralized Heartbeating(中央集約型ハートビート)
    • 全ノードが中央にハートビートを送信する
  • Ring Heartbeating(リング型ハートビート)
    • 両隣のノードにハートビート送信するパターン
    • 反時計回りの方向にあるノードだけにハートビートを送信するパターンもある
    • Centralized Heartbeating よりは良いが,2箇所が同時に故障すると,Completeness を失ってしまう可能性がある
  • All-To-All Heartbeating(全ノード型ハートビート)
    • 全てのノードにハートビートを送信する
    • Completeness は保証できるが,オーバーヘッドが大きくなりすぎてしまう
  • Gossip-Style Heartbeating(ゴシップ型ハートビート)
    • 各ノードは { Address, Heartbeat Counter, Time (Local) } から構成されるテーブル情報を個々に保持する
    • ゴシップメッセージを受けたときにテーブル同士をマージする
    • マージの際にハートビートカウンターが新しい場合,その値で更新する(ただし,ローカルタイムは非同期のため,各ノードの時間にする)
    • T(fail) 秒間ハートビートカウンターが更新されなかった場合,故障と判定し T(cleanup) 秒後にリストからメンバーを削除する
    • T(fail) 秒後に即削除をしてしまうと,別のノードからまだ T(fail) 秒が経過していないリストが送られてしまい,新規ノードであると認識してしまう問題が起きる
    • よって,一般的には T(fail) = T(cleanup) で同じ秒数を設定する

Lesson 3: Grids

例として,コロラド大学で実装された気象予報システム RAMS (Regional Atmospheric Modeling System) は,256個以上のプロセッサーを使って予測計算をしていた.簡単に言えば HPC (High Performance Computing) を使っていたことになる.スーパーコンピュータを使うことなく,分散して,並行して同様の処理をするのが,グリッドと言える.グリッドを実現するときに,ジョブを細分化した DAG (Directed Acyclic Graph) のスケジューリングを考える必要がある.どうやってジョブをアロケートするか?

イントラでグリッドを行う場合,HTCondor がよく使われる.例えば,学生が使うマシンは夜間は余剰リソースとなり,そこにアロケートしていく.例えば,ジョブが実行中のマシンが起動されて割り込まれた場合は,すぐに処理を停止する.再実行可能なタスクになっているため,すぐに別のマシンに投げることができる.大学間などグローバルに接続したグリッドを行う場合,Globus がよく使われる.サイトごとにジョブをアロケートして,サイト内(イントラ)のスケジュールはサイトに任せる.

Interview

全部見れてなくて TODO にしてある.

Coursera で "Cloud Computing Concepts, Part 1" Week 1 を受講した

Coursera

Coursera でイリノイ大学の講義 "Cloud Computing Concepts, Part 1" を受講してる!

Week 1 に関して個人的な勉強メモをまとめた.

Week 1 : 期間

  • 2016/08/29 - 2016/09/04

Week 1 : アジェンダ

  • Week 1: Orientation, Introduction to Clouds, MapReduce
    • Orientation
    • Basic Computer Science Fundamentals
    • Know Your Classmates
    • Week 1 Overview: Introduction to Clouds, MapReduce
    • Lesson 1: Introduction to Clouds
    • Lesson 2: Clouds are Distributed Systems
    • Lesson 3: MapReduce
    • Interview
    • Homework

Basic Computer Science Fundamentals

講義の本題に入る前にコンピュータサイエンスの基礎を確認するレッスンになっていた.大きく以下の6項目に関してザッと学んだ.

  • Basic datastructures
    • Queue : FIFO (Insert / Remove)
    • Stack : FILO (Push / Pop)
  • Processes
    • プロセスの構造
      • ヒープ
      • レジスタ
      • プログラムカウンタ
      • スタック
  • Computer architecture
    • プログラムをコンパイルするとマシン語に変換できる
    • 命令を CPU が実行する
  • O() notation
    • アルゴリズムの計算量を計測する
    • 最悪のケースのパフォーマンスを知ることができる
    • 未ソートなリストに対して検索する場合の計算量は O(N)
    • 挿入ソート (Insertion Sort) の計算量は O(N2)
  • Basic probability
    • 一般的な確率論のこと
  • Miscellaneous
    • DNS
    • グラフ理論(ノード・エッジ・エッジコスト)

計算量(ランダウの記号)に関して,講義資料で出てきた例は一般的だったけど,宿題で出た問題が結構複雑なアルゴリズムの計算量を答える必要があって難しかった.普通に知識不足を痛感したので,改めて基礎的な部分を勉強し直した.

qiita.com

d.hatena.ne.jp

Lesson 1: Introduction to Clouds

クラウドプロバイダとして AWS や Azure がある話や,パブリッククラウドとプライベートクラウドの違いなど,基本的な話から始まった.データセンターのトポロジーとして,コアスイッチの下に複数のラックが存在して,ラックごとにサーバが紐付いているという話もあった.

現在のクラウドコンピューティングの特徴として以下の4項目が挙げられていた.まぁ一般的な話だとは思う.

  • Massive scale
  • On-demand access
  • Data-intensive Nature
  • New Cloud Programming Paradigms
    • MapReduce / NoSQL / Cassandra

個人的に面白かったのはデータセンターの効率性(グリーングリッド)の話だった.「水使用効率 : WUE (Water Usage Effectiveness)」と「電力使用効率 : PUE (Power Usage Effectiveness)」の話が出てきて,基本的には施設全体の消費量と IT 機器の消費量が近いほど効率が良いとされている.全く知らなくて勉強になった.他には関連して,冷却設備の紹介もされていて,クラウドコンピューティングの物理を支えているのはこういうテクノロジーなんだよなと改めて認識させられた.

以下に参考資料になっていた Microsoft のデータセンターの紹介動画を貼っておく!

www.youtube.com

Lesson 2: Clouds are Distributed Systems

クラウドは分散システムのニックネームのようなもので,P2P や Grid や Clusters などを含んでいるという話だった.

Lesson 3: MapReduce

最後のレッスンは MapReduce の解説だった.最初は Hadoop の基本的な知識があれば理解できる内容で,Map フェーズとは?Reduce フェーズとは?ワードカウントに適用するとどうなる?という話だった.

次に MapReduce のスケジューリングの話で,YARN (Resource Manager / Node Manager / Application Masters) の話が出てきた.正直 YARN のことはさっぱりわからなくて,調べながら講義を聞き直したりした.あとは MapReduce の対障害性に関しても解説があった.サーバが故障した場合,リソースマネージャが停止した場合など.

Interview

全部見れてなくて TODO にしてある.

Amazon Elasticsearch Service で Kibana にアクセスポリシーを設定する方法ってある?

Amazon Elasticsearch Service に含まれてる Kibana に対して IP ベースのアクセスポリシーを設定したいと思って検証していたが,うまくできなかった.うまくできなかったけど,試したことを残しておこうと思う.もしかしたら僕の調査不足なだけかもしれないので,もし設定する方法があったら教えて頂きたいなと!!!

設定したかったこと

本番環境で Amazon Elasticsearch Service を運用することを考えたときに「開発端末から誤って更新系のクエリを飛ばしてしまったというような事故は防ぎたいけど,オフィスからは Kibana に対するアクセスだけは許可して分析できるようにする」という設定をしたかった.

Amazon Elasticsearch Service では IP ベースのアクセスポリシーを設定することができるので,オフィスの IP を設定すれば良いのだが,ドキュメントを見ても Kibana に特化した ARN や Action はなく,どうするんだろう?と思った.Fluentd から Amazon Elasticsearch Service にログを流したりする通常のユースケースでは,EC2 に IAM ロールを適用すれば良いから,Kibana のためだけに IP ベースのアクセスポリシーが使えたら嬉しい.

試したこと(結果的にうまくできなかった)

まず,アクセスポリシーを設定せずに Kibana にアクセスすると,以下のエラーが出た.

{"Message":"User: anonymous is not authorized to perform: es:ESHttpGet on resource: xxxxx"}

なるほど,ドメインに対して es:ESHttpGet の権限を与えれば良いのかな?と思って,以下のアクセスポリシーを設定してみた.IP zzz.zzz.zzz.zzz に対して,ドメイン全てのリソースに es:ESHttpGet を許可している.

ちなみに es:ESHttpGet だと Elasticsearch に対する参照系のリクエストは行えてしまうが,そこは破壊的な操作にならないという前提で,今回は良いかなと考えていた.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "es:ESHttpGet",
      "Resource": "arn:aws:es:ap-northeast-1:111111111111:domain/xxxxx/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "zzz.zzz.zzz.zzz"
        }
      }
    }
  ]
}

すると,今度は Kibana にはアクセスできるようにはなったが,Kibana の設定情報を管理している .kibana-4 インデックスにアクセスできないというエラーが出た.確かに Kibana でダッシュボードを作ったりすると .kibana-4 に書き込むわけだし,es:ESHttpGet だけじゃダメだなというのは納得感があった.

Error: Unable to check for Kibana index ".kibana-4" Error: Authorization Exception

f:id:kakku22:20160909213002p:plain

なるほど,それなら追加で .kibana-4 インデックスに対してフル権限を与えたらどうか?と思って,以下のアクセスポリシーを設定してみた.IP zzz.zzz.zzz.zzz に対して,ドメイン全てのリソースに es:ESHttpGet を許可して,.kibana-4es:* を許可している.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "es:ESHttpGet",
      "Resource": "arn:aws:es:ap-northeast-1:111111111111:domain/xxxxx/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "zzz.zzz.zzz.zzz"
        }
      }
    },
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "es:*",
      "Resource": "arn:aws:es:ap-northeast-1:111111111111:domain/xxxxx/.kibana-4",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "zzz.zzz.zzz.zzz"
        }
      }
    }
  ]
}

すると,さっきとはまた違うエラーが出た.さっきは Unable to check で今回は Unable to create だった.

Error: Unable to create Kibana index ".kibana-4" Error: Authorization Exception

あー,これじゃあ .kibana-4 のタイプにアクセスできないなと気付いて,追加で .kibana-4/* にも es:* を許可した.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "es:ESHttpGet",
      "Resource": "arn:aws:es:ap-northeast-1:111111111111:domain/xxxxx/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "zzz.zzz.zzz.zzz"
        }
      }
    },
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "es:*",
      "Resource": [
        "arn:aws:es:ap-northeast-1:111111111111:domain/xxxxx/.kibana-4",
        "arn:aws:es:ap-northeast-1:111111111111:domain/xxxxx/.kibana-4/*"
      ],
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "zzz.zzz.zzz.zzz"
        }
      }
    }
  ]
}

すると,やっと Kibana の画面は開けるようになったけど,以下のエラーが出ていて,コンソールログを見たら,実際のデータを格納しているインデックスに対する POST 権限が無いというエラーが出ていた.えっ POST 投げるの?なぜ?という感じ.

Discover: An error occurred with your request. Reset your inputs and try again.

f:id:kakku22:20160909213020p:plain

ここまで試して,今日のところは諦めた.どうしたら良いんだろ!!!

プロキシを通す案

AWS Blog に "How to Control Access to Your Amazon Elasticsearch Service Domain" という記事が上がっていて,"Proxy-based access to Amazon ES from Kibana" という構成が紹介されていた.ようするに,プロキシサーバの IP に対してフル権限を与えておいて,別途アクセス制御ををした Kibana からプロキシサーバを経由してアクセスするという話だと思うけど,この Kibana って Amazon Elasticsearch Service に含まれてる Kibana ではなく,独自の Kibana だよね?一般的な Kibana なら設定で参照する Elasticsearch のホストを指定できるけど,Amazon Elasticsearch Service だとそういうカスタマイズはできないはずだし,構成図的にも AWS ネットワークの外側にいるし.うーむ.

Amazon Elasticsearch Service で改善されると嬉しいこと

アクセスポリシーを変更すると,ドメインのステータスが Processing になって,完了すると Active になる.ダウンタイム無く変更できるのは嬉しいんだけど,待ち時間があまりに長すぎる.結構波があるけど,早くて5分,遅いときは10分以上のときもあった.インスタンスタイプの変更やディスクサイズの変更ならまだしも,アクセスポリシーの変更だしサクッと完了してくれると,ストレス無く運用できる気がした.改善されると良いなぁー.

余談 : 失敗した話を書く理由

今回,最終的にうまくできなくて,誰得な情報になってしまっている気もするけど,nobolycloud Track 7 を聞いていたら,zembutsu さんが「失敗した話をもっと書くべきでは!」みたいな話をしていて,凄く共感できたので,今回書いている.もしかしたらアドバイスをもらえる可能性もあるし,書くことによって客観的に気付く可能性もあるし,書くメリットはあるよね!と思っている.

cloudinfra.audio

関連記事

kakakakakku.hatenablog.com

「Hatena Engineer Seminar #6」に参加して Web オペレーションの知見を聞いてきた

レポートを書くのが遅れて開催から既に1週間たってしまったけど,8/31 に「Hatena Engineer Seminar #6 〜インフラ編〜」に参加してきた.抽選倍率5倍以上の人気勉強会だったから参加できて良かった!あと東京オフィス(青山)にはじめてお邪魔した!

hatena.connpass.com

既に開発者ブログで発表資料が公開されている.

developer.hatenastaff.com

はてなのログ運用これまでとこれから / id:wtatsuru

  • access_log / error_log / app_log を扱っている
  • 構成図
    • access_log
      • rsyslog で飛ばしてストレージサーバに保存する(grep など雑に分析する)
      • ウェブサーバから S3 に飛ばして二重化してバックアップしている(EMR / BigQuery で分析する)
        • EMR を捨てて Embulk + BigQuery に移行中
  • ベストエフォートでログ転送をしている
    • 100 SLA が求められる場合は別途設計して考える
  • Mackerel にメトリクスを飛ばしたり Elasticsearch + Kibana を使ったりしている

最近 Fluentd + Amazon ES + Amazon ES Kibana を使ったログ基盤を再構築していることもあって,似てるなーと思いながら聞いていた.access_log を2系統に飛ばして冗長化しているのは真似しようと思った.ただログ基盤って側面で考えると,構成図は結構カオスなのでは?と思ったりもした.最初に話があった通り,サービス運用で10年以上の歴史があるからこその複雑さだとは思うけど,分析やモニタリングをすることを考えると,もう少し統一的な整理が必要そう.

はてなのサーバプロビジョニングについて / id:hagihala

  • プロビジョニング(物理)
  • プロビジョニング(仮想)
  • まだ chef-solo を使っている
    • パフォーマンスの課題があって使い続けている
  • リポジトリ名 : chef-repo2(mainline のブランチ名は staging
  • Mackerel の Role と Chef の Role を紐付けて管理している
  • 独自の knife-saba コマンドを使ってプロビジョニングができる
  • Packer を使って AMI を作っている

Chef と Mackerel を紐付けて運用するアイデアは興味深くて,もう少し踏み込んだ事例を聞いてみたかったなー!と思う.Chef attributes は仕様自体がカオスって話は同意だけど,特段 Chef の学習コストが高いとは思わないし,Chef 普通に良いのでは派.Serverspec などのインフラ CI は特にやってないらしく,ちょっと意外だった.

MySQL運用とらぶるすとーり〜2 / id:ichirin2501

  • インフラの仕事ってイベント駆動では?
  • テーブルの行数制限
    • Rows : 4294967295
    • MySQL 4.0 & MyISAM → MySQL 5.1 & InnoDB にアップグレード
    • configure オプションを見る習慣を
    • 多段階スレーブ (4.0/5.0/5.1) と段階的なリリースで切り替え完了
  • binlog 破損
    • バイナリを読んで復旧した

面白かったー!僕はバイナリ読めません...!普通に考えてツライ話なのに楽しそうに障害対応してる姿が想像できた.圧巻の技術力!!!

アプリケーションエンジニアからみたはてなのインフラの話 / id:KGA

  • エンジニア分類
    • アプリケーションエンジニア
    • インフラエンジニア(サービス横軸)
    • セールスエンジニア(Mackerel 専任)
  • アプリケーションエンジニアから Chef リポジトリに PR を投げたりする
    • レビューしてくれて勉強になる
  • インフラ担当と雑談する
    • 最近流行ってるミドルウェアを試す
    • ジワジワと負荷が上がってることを情報共有する
  • PWG(パフォーマンスワーキンググループ)
    • サービス関係者が定期的に集まって情報交換をする会
      • Mackerel のグラフを見たり
      • これ使ってみたいんだけどどう?

雑談は重要!僕も最近似たような課題感があって,PWG に似た会を定期的に開催しているから納得感があった.

東京にいながら仕事のほとんどを京都のエンジニアと一緒にしている私のリモートワークの話 / id:dekokun

  • チームリーダーなのに東京でリモートワークをしている
  • Toil など SRE 本に載ってる区分で日報を書いている
  • 毎日終業前に Slack Call で雑談する
  • 1 on 1 を実施している

メンバーとうまく信頼関係が築けているからこそうまく機能してるんだろうなー!と感じた.Slack Call で雑談したりするのも組織的なモチベートを考えると重要.SRE 本に沿って日報を書くのは良かった.是非真似したいところ.SRE 本全然読めてないんだけど...!

セールスエンジニアとして今後身につけていきたい技術 / id:a-know

  • セールスエンジニアの仕事
    • ハンズオンセミナー
    • プリセールス
    • テクニカルサポート
  • 自鯖で Mackerel を契約して使っている
    • テクニカルサポートで再現環境にもなる

セミナーを開催したり,テクニカルサポートを続けることによって,プロダクトの評価を大きく変えることができるし,セールスエンジニアって仕事は難しくもあり,担ってる責任も大きく,素晴らしいなと感じた.テクニカルサポート,デベロッパーアドボケイト,DevRel など関連する役職が最近話題になるけど,個人的にも凄く興味がある.人に教えることが好きな性格だし,情報をアウトプットすることも好きだし,何よりもテクノロジーが好きだから,もっと話聞いてみたい!あと自鯖がガチ構成!w

まとめ

10年以上の歴史的経緯がある中で,安定的にサービスを運用してきた話やチームの話が聞けて良かった.今回の話を聞くと,一般的によく聞く構成だったり,MySQL のバージョンが古かったりもしたけど,開発者ブログを見ると先進的な技術も採用してるようだし,7月にあった技術大会も面白かったし,まだまだ話せるインフラ系のネタがたくさんありそうだなと思った.継続的に開催されるらしいし期待!

あと Web オペレーション職を募集してるとのこと!うおおおお!

hatenacorp.jp

懇親会では id:Songmu さんと id:a-know さんとお話することができて感動!!!もっと Mackerel を使っていきたいと思ってるので,引き続きよろしくお願いします :)

余談

懇親会で「社内勉強会で発表してた監視の資料見ましたよ!」って言ってもらえて嬉しかった!うおおおお!

kakakakakku.hatenablog.com

関連エントリー

kizkoh.hatenablog.com

whywaita.hateblo.jp