コネヒト開発者ブログ

コネヒト開発者ブログ

Droidcon Boston 2019に行ってきました!

f:id:tommy_kw:20190411215936j:plain

こんにちは!

Androidエンジニアの富田です。4/8、4/9にDroidcon BostonというAndroidエンジニア向けのカンファレンスがボストンで開催されました。国内のAndroidカンファレンスのブログは比較的多いと思うのですが、一方海外に目を向けると日本語ブログが少なく、どんなカンファレンス内容か気になることはないでしょうか?今回はDroidcon Bostonに参加してきましたので、気づきやナレッジを共有します。

Droidcon Bostonって?

www.droidcon-boston.com

Droidconとは、Androidエンジニア向けのグローバルなカンファレンスで、開発者同士のつながりを深めたり、技術の知見を共有するカンファレンスです。今回参加した開催地はボストンですが、それだけではなくニューヨークやロンドンなどでも開催されている大規模なカンファレンスです。

僕はDroidconに一度も参加したことがなかったのですが、DroidKaigiの登壇者、かつDroidcon Bostonスタッフでもある@droid_singhさんから‏幸運にもDroidcon Bostonのチケットを頂きましたので、初参加させて頂きました!色んな縁があるのだなとしみじみ感じたので、日々徳を積んでいこうと心に誓いました。

カンファレンス全般

Droidcon Bostonは2017年からスタートして、今年で第3回目となります。トラックは2つあり、トータル27トークセッションと4つのワークショップがありました。DroidKaigiと比べると参加者は若干少なく規模も小さめでしたが、立ち見をすることなくどのセッションでも座って落ち着いて見ることができました。

マルチトラックイベントにおいて、気になるセッションや時間を有効活用してセッションをみたいものですよね。そんな時に役立つのがカンファレンスアプリです。全体のスケジュール確認はもちろんのこと、気になるセッションが始まる前のプッシュ通知がくるので重宝しました。キャプチャではわからないのですが、カンファレンス当日には、アプリの最下部に「JUMP TO CURRENT」というボタンが表示され、それをタップすると進行中のセッションにスクロールされるようになっていました。こちらのカンファレンスアプリのソースコードも公開されているので、気になる方はご覧ください!

f:id:tommy_kw:20190413155603g:plain

カンファレンスの楽しみといえば無料でいただけるグッズですよね。ピンバッチやシールなど頂き、さらにこんな可愛いTシャツを頂きました!

f:id:tommy_kw:20190411215854j:plain
Droidcon Boston Tシャツ

また、全体を通して全てのセッションでライブスケッチを行なっていることに気づきました。下記のセッションを見ていただくと、登壇者の横に大きなボードがあるのがわかります。セッション開始と同時に下書きなしでセッション内容を描き始めます。

f:id:tommy_kw:20190411220750j:plain
Building @ speed of thoughtのセッション

そして実際に出来上がったスケッチがこちらです!60分枠のセッションがほとんどだったのですが、限られた時間でこのクオリティって...本当すごいですよね!セッション自体を見るのはもちろんですが、ライブスケッチを見るだけでも楽しめます。

f:id:tommy_kw:20190411221230j:plain
巨大なライブスケッチ

セッション一覧

セッション内容にはJetpack、Kotlin、テスト、Firebase、Flutter、Coroutine、RxJava、ML、アーキテクチャなど様々なジャンルで構成されていました。セッション一覧スライドに関しては以下のGithubにて管理されており、今年のセッションスライドだけでなく、20172018年分のセッションスライドもキャッチアップできるようになっています。ご興味ある方はぜひご覧ください!ここからは特に気になったセッションを3つ紹介します。

github.com

Do the Loco-MotionLayout: Building animations with MotionLayout

@mikescamellさんによるMotionLayoutの紹介です。MotionLayoutがどのように機能するか基礎についてサンプルコードを基に体系的に学ぶことができます。MotionSceneとは何か、またそれを利用して状態とレイアウトから分離する方法、トランジションのトリガーとなるクリックとスワイプの利用方法、KeyAttributesを利用してアニメーションの微調整方法などまで言及されていました。

f:id:tommy_kw:20190413151129g:plain
サンプルアプリ

Destination navigation: You’re going to love the transition

github.com

@emmaxさんによるNavigationアーキテクチャコンポーネントの入門紹介です。Android開発を加速するJetpackの一つであるのNavigationの利用方法について説明になります。基本利用からSafe Args、Conditional Navigation、Deep Link、テスト方法などまで言及されていました。

Leveling Up As An Android Dev

github.com

@moyheenさんによるAndroidエンジニアのキャリアについての紹介です。Android向けの技術カンファレスなので技術的な内容のセッションは多いですが、このセッションではキャリアについて紹介されています。Androidエンジニアの各レベルで求められていることって意外とわからないものですよね。今回紹介されていた内容は以下の通りです。

  • ジュニアエンジニア
  • ミドルエンジニア
  • シニアエンジニア
  • リードエンジニア
  • マネジメント
  • その他(GDEなど)

各レベルで何をすべきか、そして今のレベルを把握することによって、次のレベルに前進するための情報を得ることができます。

最後に

ひょんなことからDroidcon Bostonに参加させてもらったのですが、グローバルなカンファレンスであり、かつ豊富なジャンルのセッションでとても刺激的でした。スライド一覧を見ていただくと興味のある内容もあると思いますのでぜひご覧ください!また、Droidconはボストンだけでなく、様々な地域で開催されているため、Droidcon Bostonをきっかけに他のDroidconにも参加して行きたいと思います。以上になります、ありがとうございました!

新米マネージャーが1on1で実践していること

f:id:itosho525:20190409183944p:plain

こんにちは。サーバーサイドエンジニアの @itosho です。

Bリーグ(日本のプロバスケットボールリーグ)がシーズン佳境を迎え、週末はDAZN漬けの毎日を送っています🏀*1

というわけで、今日はバスケの1on1の話…ではなくミーティングの方の1on1の話をしたいと思います。僕は半年ほど前からプレイングマネージャーのようなポジションでマネジメント業務をしており、その中で1on1ミーティングも定期的*2に実施しています。

1on1については導入企業も増えてきており、事例も広く公開されてるようになってきましたが、まだまだ現場の個別具体的なノウハウは世に出てきていないと個人的には感じています。そこでこの記事では半年間の振り返りと知見の共有を兼ねて、僕が1on1で実施した取り組みを4つ紹介させていただきます。

なお、前職等でも多少のマネジメント経験はありますが、ガッツリやるのは初めて+コネヒトでは初めてのマネジメント経験になるので新米マネージャーという表現をさせていただいております。

1. 1on1の目的を共有

まず、初回の1on1では目的の共有を行いました。一口に1on1と言っても、社長が実施する1on1と直属の上長が実施する1on1は役割が違います。また、個々人が1on1に対して抱いているイメージや期待値も様々です。ですので、最初にそのギャップを埋めるために僕が想定している1on1の目的やイメージなどを伝えるようにしました。

具体的には以下の目的でやるよ!ということを共有しました。

## 1on1の目的
- 設定した目標を達成するための支援 
- 生き生きと働ける(≒その人が100%の力を発揮出来る)ようにするための支援
  - もやもやしていることや本当はやりたいこと何でもいいので話してください
- よろず相談
  - 会社関係なくキャリアのお悩みとかあれば(話したい人はプライベートの話でもOK)

また、これは雰囲気というかただのイメージの共有ですが、野球で例えると僕(メンター)は監督やコーチではなくキャッチャーでメンバー(メンティー)はピッチャーだよということを伝え、1on1はキャッチボールをするような場であることもセットで共有しました。

2. 1on1シートの作成

目的の共有と併せて、面談シートのような1on1シートを作成しました。個人的に1on1では雑談も大切だと思っているので、あまりガチガチにやりたくないと思っています。とは言え、やってる感だけ出して、目標の達成支援が出来ていないなら、それはメンバーの貴重な時間をいたずらに奪っているだけなので、トラッキングも兼ねて1on1の数日前に1on1シートを用意して事前に話したいことなどを書いてもらうようにしていました。また、僕からも気付いたことがあれば積極的に書くようにしていました。ただ、1on1を受ける側からすると準備のコストが高いと1on1が億劫になってしまうこともあるので事前に書くのは任意にしていました。

1on1シートのフォーマットは何度かアップデートを行い、現在は以下のような形で運用しています。

## YYYYMMDD: 第X回

### お話
- 事前に話したいことがあれば書いておいてください!

### プチ振り返り&フィードバック

#### よかったこと
- 最近よかったことや上手くいったことをお互い書くコーナー

#### よくなかったこと
- 最近よくなかったことや改善したほうがよいことをお互い書くコーナー

### Todo
- メンターの宿題を書くコーナー

簡単に説明すると、最初のお話枠は何でもよいので話したいトピックがあれば書いてもらっています。2つ目のプチ振り返り&フィードバック枠は日頃からカジュアルにフィードバック出来る場があったほうが良いかなと思い、メンバーが自分の行動でよかったと思うことやよくなかったと思うことを書き、僕はその人を傍から観察して、よかったと思うことやよくなかったと思うことを書くようにしています。基本的にはポジティブなフィードバックが多めですが、お互いに書き、それを共有することで期待値調整や認識齟齬の早期解消を行っています。最後のToDo枠は1on1の過程で発生した僕がやるべきタスクを忘れないようにメモします。ここで書いたタスクは次の1on1で進捗を報告したり、対応したタイミングで共有したりしています。

3. フィードバックワークの実施

コネヒトではOKRによる目標設定をしているのですが、その過程で中間振り返りを実施するタイミングがあります。そこで目標達成のためにいつも1on1より長めに時間を確保し、目標の振り返りと併せてワークショップ形式でフィードバックを行いました。

いわゆる、ジョハリの窓に近いようなワークなのですが、目的としては、

## フィードバックワークの目的
- 自身の振り返りと他者の振り返りを掛け合わせることで、気付きと学びを得る。
- そして、行動を変える一歩を踏み出すための後押しをする。

というのを掲げ、以下のような流れでワークを行いました。

## フィードバックワークの流れ

### 1. メンバーが以下の内容を付箋に書く
- 目標を意識して移せた行動や言動
- 目標を意識していたが出来なかった行動や言動

### 2. 僕が以下の内容を付箋に書く
- 目標に沿っていたと思う行動や言動
- もう少し目標に沿わせられたと思う行動や言動

### 3. それぞれの付箋を発表する
- 発表された付箋をメンバーが以下の画像のような四象限にマッピングする

### 4. マッピングされた付箋をみながら質問し合う
- 何故出来ないか深掘りしたりどうすれば出来るようになるか考えたり

### 5. 最後に今後注力したいポイントを1つ決める
- 決めたものは1on1シートに記載する

f:id:itosho525:20190409154121p:plain

やってみた所感としては、対面でやるフィードバックよりもコトに向かいやすい(僕のフィードバック力不足に依るところも多いですが)点が非常に良いなと感じました。

4. オフサイトでの実施

普段の1on1はオフィス内*3で行っているのですが、たまにカフェなどのオフサイトでも1on1を実施しています。もちろん、オフィス外なのでコンフィデンシャルな話は出来ませんが、いい意味で仕事っぽくない雰囲気になり、いつもと違う話が構造的にもやりやすいので時々オフサイトでやるのは良いなと思います。ちなみに事前に苦手な飲み物がないかどうかを確認しておくことも地味に大切です。

まとめ

このようにまとめると、ややもすればいい感じに1on1をやっているようにみえるかもしれませんが、まだまだ勉強不足で試行錯誤の毎日です。それでも、僕は1on1の質はメンバーのことを考えている量に比例すると思っているので、これからも日々努力を積み重ねていきたいと思っています。冒頭にも述べましたが、1on1の現場の個別具体的なノウハウはまだまだ世に出てきていないと感じています。それは最適解が会社や職種、個人、はたまたフェーズなどの変数によって大きく異なることに起因するのも原因の一つだと思います。しかし、だからこそ様々な事例を知ることも重要だと思うので、またノウハウが溜まってきたタイミングで定期的に共有を行っていきたいと考えています。この記事が誰かのためになれば幸いです。

*1:ちなみに当方、アルバルク東京のブースターです。

*2:基本的には隔週1回30分のペースで実施していますが、頻度は各人の状況や時期に応じて適宜見直しています。

*3:オフィスで実施する場合も、会議室っぽくないスペースかつ対面にならない場所を選ぶことが多いです。

PHPerKaigi 2019にシルバースポンサーとして協賛いたします!

こんにちは。サーバーサイドエンジニアの 高野 (@fortkle) です。
さて、今日はイベント協賛の告知をさせてください!

PHPerKaigi 2019に協賛いたします!

タイトルにもある通り、PHPerKaigi 2019 にシルバースポンサーとして協賛いたします。
コネヒトではメインプロダクトである「ママリ」を始めとして開発のメイン言語としてPHPを活用しており、フレームワークとしてはCakePHPを採用しています。

phperkaigi.jp

イベント概要

PHPerKaigiはどんなイベントか、公式サイトから拝借すると

PHPerKaigi(ペチパーカイギ)は、PHPer、つまり、現在PHPを使用している方、過去にPHPを使用していた方、これからPHPを使いたいと思っている方、そしてPHPが大好きな方たちが、技術的なノウハウとPHP愛を共有するためのイベントです。

という 過去・現在・未来PHPerに向けたお祭り のようです! 他のカンファレンスと同様に公募トークがありつつ、数人で特定のテーマについてディスカッションするInteractive Round Tableや、アンカンファレンスなどちょっと違ったことも企画されているとのこと!

タイムテーブルもすでに発表されているので興味がある方は要チェックです!

タイムテーブル | PHPerKaigi 2019 - fortee.jp

3日間にかけて行われる大規模なイベントなのでどのトークを聞こうか迷っちゃいますね。 個人的には、設計やアーキテクチャの話と、PhpStorm/コードリーディングまわりの話と最終日のLTが気になっています!

最後に

ここまで読んでくださった皆様、ありがとうございました。
そして、 PHPerチャレンジ中の皆様、お目当てのPHPerトークンはこちらです!

#EnjoyPHPWithConnehito

それでは!

コネヒトではPHPerを積極採用中です!

www.wantedly.com

「やさしいかんしのご提案」をしました 〜コネヒトなりの「監視の民主化」入門〜

こんにちは! @o0h_です。
3月は・・・王様ランキング!!!!おめでとうございます🎉

王様ランキング 1巻

https://cdn-mamari.imgix.net/authorized/5c92686d-9b58-410f-8b54-0037ac110003.jpg

さて、唐突に本題なのですが
先日、入門監視を読んで思ったこと・感じたことを当ブログに投稿しました。

tech.connehito.com

今回は、ちょっとした続編のようなものになります。

先の記事では、自分自身に生じた内省や「べき論」「目指すべき地点」を中心に取り扱いました。
具体的な「私や他のメンバーが取るアクション」や「変更されていく内容」についてはスコープにしておりません。

当然、こうもデカい口を叩いた以上は、実践をしていく必要があります。
でないと・・・ダサダサ君になってしまいますよね。
そんな訳で、「実際に組織を変えていくぞ」と、その最初の一歩目として 監視の民主化に向けたキックオフ を行いました。*1

先日のブログのような内容が「概念」「抽象」だとするなら、こちらは「実践」「具体」に相当するものでもあります。
折角ですので、私と同じような課題感を持った人と共闘すべく、この場で公開してみます!

あくまで社内向けに企画・作成した内容なので、「内輪ならコンテキストがあるから、ちゃんと伝わるだろうけどさ」な部分も少なくありません。
それでも、今回の内容はある程度の一般性を保てているのではないか〜なんて考えています。

*1:先日、弊社にて開催した勉強会での私の発表内容もこの内容を想起しながらまとめたものになります

続きを読む

Slack Block Kitを使って既存ツールをカッコよくしてみた

こんにちは、 BLUE GIANT SUPREME (7) (ビッグコミックススペシャル)を読みました。金城(@o0h_)です。
読後、へーしゃで称賛が発生していました。

f:id:o0h:20190303130444p:plain
こちら、社長と私です

そんな感じで色々にSlackを利用している身のものですが、先月「新しい機能をリリースしたよ!」という発表がありました。
「Block Kit」です。

Block Kitは、「Slack投稿の表現力を上げる」「ユーザーと、より気の利いたインタラクションをつなぐことを支援する」ための新UI(のためのAPI)です。
これを利用すると、いつものSlackの投稿がとても高機能になります。

実際に触ってみたので、使い方やハマったポイントなどを共有していきます。

https://cdn-mamari.imgix.net/authorized/5c7ccc81-7170-439c-8949-0034ac110003.jpg

続きを読む

React HooksとContextAPIでFluxをやってみる

f:id:dachi023:20190226162905p:plain

CTO室エンジニアの安達 (@dachi_023) です。React v16.8で待ちに待ったHooksが (20日前に) リリースされました。そんなHooksを使ってFluxやる時ってどうするんだろう?と思ったので調べて写経してみました。

reactjs.org

書いたコード

create-react-app して出てきたものをいじって作りました。Flux化するまでに書いたコードだけを見たい場合は コミットログ が分かりやすいかもしれません。

github.com

余談: 実際書いてみて「Hooksちゃんと理解してなかったなぁ、9割くらい写経だとしても覚えるために書くというのは良いことだ」と感じられました。

やってみる

  • お題: +1 / -1 ができるカウンターの実装
  • useReducer() とContextでStoreをつくる
  • Actionの発行 → dispatch → Stateの更新 → 再描画 をやる

Context

ContextがStateを管理するための入れ物 & 伝搬役になります。とりあえず createContext() して返します。今回はdispatchも同じContext内で管理します。

import { createContext } from 'react'

export default createContext({
  count: 0,
  dispatch: null
})

Reducer

Actionを受け取って新しいStateを返します。Actionの中身は redux-utilities/flux-standard-action と同様です。Reducerの定義は Reactのドキュメント にも書いてありますが (state, action) => newState です。

export default function CounterReducer(state, action) {
  switch (action.type) {
    case 'increment':
      return { count: state.count + 1 }
    case 'decrement':
      return { count: state.count - 1 }
    default:
      return state
  }
}

ActionCreator

外部通信やビジネスロジックがないのでほぼ無意味な感じになってますが前述したflux-standard-actionに倣ってActionを生成して dispatch() します。

export function increment(dispatch) {
  dispatch({
    type: 'increment',
    payload: {}
  })
}

export function decrement(dispatch) {
  dispatch({
    type: 'decrement',
    payload: {}
  })
}

Component

作ったものをつなげていきます。

App.js

useReducer() にCounterReducerとStateの初期値を渡してstateとdispatchを取り出しProviderに突っ込めばStateの生成と値の伝搬作業が完了します。

import React, { useReducer } from 'react'
import Counter from './Counter'
import CounterContext from './contexts/CounterContext'
import CounterReducer from './reducers/CounterReducer'
import './App.css'

export default function App() {
  const [state, dispatch] = useReducer(CounterReducer, { count: 0 })
  return (
    <div className="App">
      <header className="App-header">
        <CounterContext.Provider value={{ ...state, dispatch }}>
          <Counter />
        </CounterContext.Provider>
      </header>
    </div>
  )
}

Counter.js

の処理でProviderにセットしたStateを useContext() で取り出し表示します。Stateと一緒に入れてあるdispatchを取り出してクリックイベントに仕込めばStateの更新処理までが完了です。

import React, { useContext } from 'react'
import CounterContext from './contexts/CounterContext'
import { increment, decrement } from './actions/CounterActions'

export default function Counter() {
  const { count, dispatch } = useContext(CounterContext)
  return (
    <>
      <h2>{count}</h2>
      <button onClick={() => increment(dispatch)}>Increment</button>
      <button onClick={() => decrement(dispatch)}>Decrement</button>
    </>
  )
}

できあがったのがこれ

ちゃんと増えたり減ったりするようになりました!

f:id:dachi023:20190226160647g:plain

まとめ

  • 今までのClassベースのComponentとは書きっぷりがだいぶ異なるので最初とっつきづらいのかもなと思いました、1回でも真面目にやると「なんだ全然できるじゃん!」という感じですが。
  • 複雑なことしないのであればFluxライブラリなど使わずにHooksで実装しちゃってもいいかもしれないですね。結構使えそうじゃないかな?と思ってます。

参考記事

AmazonAurora カスタムエンドポイントのフェールオーバー時の挙動についての検証

こんにちは。インフラエンジニアの永井(shnagai)です。

昨年11月にリリースされたAmazon Auroraのカスタムエンドポイントを運用していて、先日ある検証環境でフェールオーバーが起きた際に考慮していなかった事態が起きたので、仕様を確認するがてらカスタムエンドポイントのタイプ別にフェールオーバー時の挙動をまとめてみました。

カスタムエンドポイントについては下記をご参照ください。 自由にAuroraインスタンスを組み合わせて、用途別にAuroraのエンドポイントを管理出来る機能で、これまで泣く泣く続けていたmysqlのbinlogレプリ運用から解放されるようなうれしさがあります。 docs.aws.amazon.com

起きた事象

Auroraクラスタにフェールオーバーが発生した際に、当然リードレプリカがマスター昇格します。その際に、カスタムエンドポイントのノードが0になりカスタムエンドポイントへのDB接続が不可となりました。

これは、下記環境の説明にあるようにREADER TYPEでカスタムエンドポイントを作成していたので、登録していたリーダーインスタンスがREADER TYPEの条件不一致になりメンバから外れたのが原因でした。 リーダーエンドポイントだと、よくあるLBのSorry設定のように、ノードが0になればマスターが一時的にメンバに入りノード0を防ぐような挙動をしてくれますがカスタムエンドポイントではそのような挙動はありません。 今回の検証では、リードレプリカに降格したインスタンス(旧ライターインスタンス)が、自動的にカスタムエンドポイントに登録するような設定を見つけるのがゴールとなります。

問題が起きたカスタムエンドポイントの環境

  • Auroraクラスタで、ライターインスタンス1台、リーダーインスタンス1台構成で運用
  • カスタムエンドポイントは下記条件で作成し運用
    • READER TYPE
    • メンバシップルール内の[今後追加されたインスタンスをこのクラスターにアタッチ]はDisable ※この設定はAuroraレプリカを追加する際に意図せずエンドポイントに追加されるのを防ぐ意図で入れたのですがこれが仇になりました。。
    • 静的リストで、リーダーインスタンス1台を登録

Auroraのカスタムエンドポイントの主な設定値

はじめに前提知識としてAuroraのカスタムエンドポイントに主な設定値の内容を確認しておきます。 主な設定値は2つです

タイプ指定

Any or READERでカスタムエンドポイントのルールを指定する

type 説明
READER 読み取り専用の Aurora レプリカである DB インスタンスのみが、READER カスタムエンドポイントの一部となることができる
ANY 読み取り専用の Aurora レプリカと読み取り/書き込みのプライマリインスタンスの両方が ANY カスタムエンドポイントの一部となることができる

メンバーシップルール

  • 静的リストか除外リストを用いて、カスタムエンドポイントに所属するインスタンスを指定する
  • [今後追加されたインスタンスをこのクラスターにアタッチ]するか否かを選択する ※今回の検証ではここが肝だった

検証

6つのパターンからフェイルオーバー時に降格したマスターノードがカスタムエンドポイントのメンバに自動的に追加される設定を探りました。

検証

  • テスト用のAuroraクラスターを作成
  • クラスタには、1台のライターノード(test-custom-endpoint)と1台のリーダーインスタンス(test-custom-endpoint-ap-northeast-1c)を用意
  • 6パターンのカスタムエンドポイントを作成し、フェイルオーバー時の挙動を確認

結果

②の構成でカスタムエンドポイントを作ることで、フェイルオーバー時に降格したインスタンスがカスタムエンドポイントに追加されることが確認出来ました。

また、⑤⑥の構成であれば静的リストの中からレプリカのみがカスタムエンドポイントのメンバーとして管理されることがわかりました。

※はてブでコメントいただき「ライターインスタンスは静的リストに入れておいてもライターのうちはREADER TYPEのメンバにはならないからそれをうまく使うという」気づきを得ました。

No TYPE 追加インスタンスのアタッチ 静的リストに登録するメンバ 予想 結果
READER Disable レプリカのみ メンバいなくなる メンバいなくなる
READER Enable レプリカのみ メンバいなくなる or 降格したインスタンスがメンバイン 降格したインスタンスがメンバイン
ANY Disable レプリカのみ そのまま(昇格したライターのみ) そのまま
ANY Enable レプリカのみ そのまま or 降格したインスタンスがメンバイン そのまま
READER Disable レプリカとライター 降格したインスタンスのみ 降格したインスタンスのみ
READER Enable レプリカとライター 降格したインスタンスのみ 降格したインスタンスのみ

最終的にどんな構成にすればいいのか

カスタムエンドポイントを使いたいよくあるケースは下記のようなパターンかと思います。

  • マスターにはサービスからの書き込みトラフィックが流れる
  • 複数台あるレプリカを束ねるカスタムエンドポイントにサービスの読み取りトラフィックが流れる
    • フェイルオーバー時は、このサービス用のカスタムエンドポイントのいずれかがマスタ昇格
  • 分析用にAuroraのレプリカを作ってそこは分析のSQLだけが流れるような構成

下記のような構成を取ることで、カスタムエンドポイントの本来の良さを生かしてAuroraレプリカへのトラフィック分散が出来るのではないかと思います。(さらばbinlogレプリ)

  • レプリカのスケールアウトはあまり行われず、別用途のレプリカが追加される可能性の高い環境で運用したい場合は⑤の構成
  • レプリカのスケールアウトを行う可能性があり、その際にシームレスにカスタムエンドポイントに追加されてほしい場合は⑥の構成

※カスタムエンドポイントはGUIから作るとAny typeになるので、READER typeのエンドポイントを作るにはAWS CLI等からの作成が必要

サービス用のカスタムエンドポイント

READER type + 新規インスタンスのアタッチ有or無 + 静的リストにライターとサービス用のレプリカを登録 + 所属するリードレプリカのFailOver優先度を0(最優先)にしこの中からフェイルオーバー時のマスター昇格が行われるようにする

分析用のカスタムエンドポイント

READER type + 新規インスタンスのアタッチ無し + 静的リストには分析用のレプリカを登録 + 所属するリードレプリカのFailOver優先度を15(優先度最も低い)にしてフェイルオーバー時のマスタ昇格は行われないようにする

f:id:nagais:20190222174722j:plain

参考までに画面キャプチャ

f:id:nagais:20190218163647p:plain f:id:nagais:20190218163659p:plain

f:id:nagais:20190218163715p:plain f:id:nagais:20190218163723p:plain

f:id:nagais:20190218163740p:plain f:id:nagais:20190218163749p:plain

f:id:nagais:20190218163801p:plain f:id:nagais:20190218163812p:plain

f:id:nagais:20190222174642p:plain f:id:nagais:20190222174656p:plain

コネヒトでは変化を恐れずに良いものを取り入れながらサービスの信頼性向上をミッションに一緒に働く仲間を探しています。 少しでも興味もたれた方は、是非気軽にオフィスに遊びにきていただけるとうれしいです。

www.wantedly.com