色はスタッフ用がサックスブルー、プレゼント用(登壇者、個人スポンサー)がブラック。本が青だからやっぱり青系でしょ」というコンセプトでした。印刷してから3ヶ月なら版の追加料金がかからないため、「試しに1枚刷る→問題なければ全員分刷る」というステップを取りました。実際、最初の試し刷りでは、実際に着てみるとロゴが大きすぎることに気づいたので、このステップを取ってよかったです......。一歩間違えたらスタッフ全員に配布されていたクソデカロゴTステッカーステッカーって、扱ってくれる会社も多いし、選べるオプションも多くてホントに困りました。そのため、以下の基本方針を決めてから、いくつかのサイトを見て回りました。ステッカーと同じ感じになります。再剥離のりマットラミネート四角形裁ち落とし5x5cm裏スリットなしシートの形は40パス以内無料7営業日Sのところでステッカーの外枠もカーブしてるのが素敵。こちら、スタッフの奥さん(デザイナーの方)のアイディアで、パスの調整までしてくれました。しているメンバーと「ここがよい」「この点ではこちらがよい」と議論するのは楽しかったです。ここだけで、苦労の元が取れた気がしました。全体としてのバランスにはあまり配慮できなかったことでした。そのあたりは他のメンバーに助けられましたが、そういう意識が最初からあれば、もっとうまくできたのでは......と反省したところです。メイン会場だから、最初から最後まで面白いセッションが聞けるだろう」と立候補しました。そんなことなかったですね。面白くなかった、という意味ではなくて、全然集中できなかった、という意味で......。繋いで大部屋にした状態で300名。質疑応答をする・しないのタイムスケジュール管理インカムからの指示による臨時のアナウンス追加などなどがあり、講演を聞いてる最中もまったく集中できませんでした(気づくのが遅い)。途中で代わってもらえたら、もうちょっとイベント自体を楽しめたかもですね。前日に急遽決まったオペレーションも多かったので、司会業をうまくマニュアル化できず、複数人で分担できなかったというのが今回の反省点でした。聞いていた方はどうだったんでしょうね。耳障りでなければよかったんですけど。検索して、特にネガティブなコメントはなかったので一安心してるところです。大変でしたけど、大規模なテックカンファレンスの裏側を体験することができて面白かったです。自分の興味がある技術分野で、同じ分野にいる同業者と知り合いになれて、普段会わない人(特に自分より若い人)の考えを聞く機会がたくさん得られました。して働いていて(あるいはまだ働いていないけど興味があって)、この分野の技術コミュニティに参加したいという方には、スタッフとして参加することをお勧めしたいと思います。参加したことがなければ、まずはこちらに参加してみてください。入ってもらえたら、次回の開催情報もそのうち流れると思います。これからしばらくは全講演のスライドを見て、感想ブログを読み漁る生活だ......。しながら考えが変わったこと今回の記事は年末スペシャルです。しながらやってきた取り組みについては、今年も会社のテックブログに色々書かせてもらいました(職場の理解のおかげです。いつも感謝してます)。それぞれのブログ記事の間を埋めるストーリーというか、その背景にあることについてはなかなか書く機会がありませんでした。しながら考えていたことをつらつらと書いていこうと思います。あるべき組織体制について、1年前はこう考えていました。アプリの開発状況を細かく把握しながら監視・運用すべきただ、この1年で考えが変わり、いまはこう考えています。それを支えるシステム作りに労力を割くべきこう書くと、なんか、結局当たり前の結論に帰ってきてしまった感じがしますね......。いうものだろ、と言われそうな気もします。いう過程を経てそういう考えに落ち着いたのかを振り返ってみます。1年前(2018年末)に考えていたこと去年の年末の時点で、僕個人はこういう状況でした。チームだったものを複数の開発チームにまたがる形にしました。分離してしまっていた当時の状況では、それが最適なチーム構成だろう、と僕も強く同意していました。チームの黎明期を知るメンバに繰り返しインタビューして書いた発表資料やブログ記事がありますので、そちらをぜひどうぞ。化プロジェクト」というリプレイスプロジェクトに参加してました。1人だけという状況でした。入り、インフラとアプリの両方に目配せすることで、いろいろな問題を未然に防げたという手応えはありました。して1人頑張り続けることのつらさも強く感じていました。2018年末はそんな状況でした。年に考えていたこととやったことそこから1年経って、2019年末(現時点)の状況はこう変わりました。改善活動を主導できる体制作りを目的に行われました。実は、僕は当初この分離には反対していました。特定の開発チームに割り当てるのは、短期的には有効だけど、長期的には持続可能じゃないという考えに変わりました。して張り付け続けるつらさを実体験したからです。疲弊して、退職されてしまうだろうと......。どれくらい大変かの具体的な話は、リプレイスプロジェクトが終わったときのブログ記事に書いたので、よかったらこちらをどうぞ。勉強会で、いろいろな他社事例に触れたことです。事例では、開発チームへの監視・運用の移行がここまで現実に可能なのかと驚かされました。ついて以下のイベントで初めて知り、懇親会でメルカリのエンジニアに詳しい話を聞いて感銘を受けました。アプリ開発者の責任分界点を明確にするため」という目的さえブレなければ、マイクロサービス化を推し進めていいのではないかと考え始めました。メルカリの事例に強く影響を受けて、その後、自分の現場でも、アプリ開発者に監視業務を移行するためのアラート通知システムを整備しました。マイクロサービス化まではまだ進んでいませんが、責任分界点を明確にするためには、これからマイクロサービス化を段階的に進めていく必要があると思っています。開発チームを巻き込んだ監視システムの全体像(下記ブログから引用)backlog.comちなみに、開発チームに1年以上いたおかげで、アプリ監視の業務設計ができて、結果的にこのアラート通知システムも作れました。その点は、1年以上悪戦苦闘したのも無駄な努力ではなかったのかな、と。業務について考えるにあたって、他社の事例を聞くのはとても参考になると実感した1年でもありました。来年1/25(土)に開催されます。司会としてスタッフ参加している予定です。チケットは売り切れてしまっています(すみません!)が、発表スライドは後ほどいろいろな登壇者が公開してくれると思います。僕もイベント当日は見てる余裕がなさそうなので、あとから発表スライドやレポートブログなどをゆっくり読ませてもらうつもりです。来年末も、今とはまたいろいろ考えが変わってるのかなあ。ES)を本格的に使う機会があって、認証周りの仕様で苦労させられました。周りの情報は意外と見つかりませんでした。使うにあたって調べた情報をまとめてみます。ベースにしたマネージド型サービスです。社*1が主に開発しているオープンソースソフトウェア(OSS)です。呼ばれる拡張機能があり、その大半は有償オプションで利用できる。呼ばれるサービス群の一つ。デプロイされるマネージドサービス。等に固有の機能はない。サービス群と統合するために、各種拡張が行われている。機能は含まないが、同等の機能が一部実装されている。同一ではない、と宣言されている。この記事では触れない。大きく違っている機能が多いからです。この記事で解説する認証・認可の方法も、そのような機能の一つです。「ドメイン」という概念が新たに導入されています。クラスタは1対1対応です。ドメインとは何ですか?」)。設置するかを選ぶ必要があります。アクセス」と呼ばれます。アドレスの有無以外に、機能面でも少し違いがあります。「制約事項」の項をご覧ください。ドメインのアクセスポリシーについて」の項でわずかに触れられている(しかし結構重要な)認証・認可についての制約事項の話です。ベースのアクセス権限ポリシーを適用することはできません。ベースのポリシーを引き続き利用できます。ドメインに対して、セキュリティポリシーとセキュリティグループを設定できます。アクセスの場合のみ設定できます。ドメインに対するセキュリティポリシーには、以下の3種類を利用できます。詳しく書かれています。ベースのポリシーは使えません。この関係を図に表すと、以下のようになります。アクセスの認証・認可機能は同等なんですね。よかったよかった」と思われましたよね。僕も最初そう思いました。ない、そうじゃないんですよ......。ベースのポリシーは組み合わせて使えます。複数のステートメントを並べて書くこともできます。ユーザに対してのみ、すべての操作を許す」というセキュリティポリシーは、以下のように書けます。]}この関係を図に表すとこうなります。ベースのポリシーは使えます。セキュリティグループも設定することができます。図にするとこうなります。セキュリティグループ1」という横の繋がりは強制できません。さっきパブリックアクセスの例に挙げた、以下のようなアクセス制御はできません。アドレスでユーザを識別して認可するのは諦めよう!と考えたとします。署名のみを許可しています。統一できる、というのはもちろん強いメリットと言うこともできます。認証情報は集中管理できたほうがいいですよね。自分は実際に使ってみて、3つの問題を感じました。サブコマンドがあるじゃないか」と言うかもしれません。コマンドで実行できます。署名を意識する必要はありません。コマンドの範囲外です。対応するコードを書くのかと言われるとちょっと......。アクセスを新たに追加したい場合に、「インスタンス1にはインデックスAへのアクセスを許可し、インスタンス2にはインデックスBへのアクセスを許可したい」と思ったとします。ロールの付け替えが必要になります。あちこちから参照していたりしたら、付け替えは地獄の作業になります。