もう 16 回目なのか。AUG にまた参加してきました。
最近は compass で参加管理をしているから、compass の AUG グループにジョインすると
AUG の開催通知が来るらしいよ。
以下、適当なメモ。
gumi 本間さん GHE からの移行
1. GHR 時代
2012 年
Dev には好かれるが Ops には好かれない
Ops まで範囲を広げると金がやばい
これはどこでもそうなのだろうね。
Github という一種のブランド物になってしまっている。
gumi のサーバはすべて AWS で運用
しかし AWS に当時はおけなかったので、
自前サーバに置くにはパフォーマンスが安定しない
ROOT 取れないから監視も大変
GHE の困る点はイメージで OS ごと渡されるので、
中身がいじれないのと ROOT が取れないこと。
インストールやアップグレードは確かに楽だが、
代わりにチューニングの余地がないのが困るね。
2. 解決したかった課題
ライセンス料
海外や協力会社や非エンジニアのアカウントが増えてライセンスが！
非エンジニアは共通アカウント運用をしていたときもあったらしい。
まぁ仕方ないといえば仕方ないが、セキュリティ観念と利用ポリシー的には継続できないよね。
GHE はボリュームライセンスじゃないから、一人いくらでカウントされる。
ライセンスの増減はしやすいけど、別に利用頻度が高くない人にも
ライセンスを発行しないといけないのが地味に効く。
権限管理
Crowd と Google Apps と連携
海外のどこ拠点もすべて Google Apps を導入している。
Stash は細かくリポジトリの権限を設定できる
いいなー GoogleApps。グループの同期もできるんよね。
AWS の機能
Stash のサーバ構成
EC2+EBS（IO 高めなので EBS
RDB
AWS だと標準でできるものでも、自前で立てると自分で用意しないといけないのは、
AWS に慣れてしまうとかなり面倒に感じてしまうもの。
特にバックアップが簡単になるのが大きい！
初めて知ったがサーバーの巻き戻しもあるのか！数分前にとか！
3. Stash 導入時と運用 TIPS
数十 GB のリポジトリのせいで LoadAvg が高くなる。
これは IO のせい。
Git のバージョン特有のバグだった（1.8.x 系だと Stash で重くなる）
結局 Git バージョンのせいだったけど、
そこに行き着くまでに商用サポートが有用だったという話。
OSS だと誰かが見つけてくれるのを待つか、自分で見つけないといけないからね。
パブリックアクセスの禁止
# vi stash-config.properties
feature.public.access=false
画面上から無理やり消していたが、設定方法あったのか。。
2 年でやったこと
shellshock, heatbleed 対応
git,jdk,stash3.x へバージョンアップとか
バージョンアップ待ちとかになるないように商用サポートケチらないほうがいいよという話。
4. 要望
snippets
有償でもあるけど履歴管理できない
いわゆる gist にあたるもの。
あの有償アドオン履歴管理できないのかよ……
オンライン編集
有償でもあるけど標準でほしいね
Bitbucket Ondemand にある機能は、Stash にも標準搭載して欲しい。。
フックの充実
これ重要！
Stash ってデフォルトでフックが用意されてないよね。
こちらで全部提供しなきゃ行けないのが結構つらい。
まとめ
Github になれた人でも使えるよ
オープンソース＝無料じゃないよ
OSS 運用する上で中身を知らないといけないしね。
それをしっかりやろうとしたらかなり大変だから商用のほうが結局楽という。
セキュリティとか甘々でいいなら OSS で作りっぱなしでいいけどね。
Glenn @Atlassian
※自分翻訳＋翻訳の方が言っていたことのメモ
シドニーから来たよ
プラットフォームエンジニアリングとして働いている
社内システムのみを扱っている
すべての製品を見ているけど、専門家ではなく運用管理している
Atlassian 社の方で社内システムエンジニア。
こちらから見たら中の人、さらに中の人。
社員が増えたので SystemAdmin を３つに分けた
・プラットフォームエンジニア
→ 社内システムの管理
要望があれば作り、改善を行う
・サービスオペレーション
→ リクエストに対して作業を行う
・サービスリライアビリティ
→ ひとつひとつのアプリに付いている特定ツールの専門部隊
これは参考になる分け方！
明示してないが結構こういう形に自然となっているかも。
サービスリライビリティって聞かない言葉だけど、
「Service Reliability」サービスの信頼性を守る部隊って解釈でいいのかな。
SysAdmin Q&A
何台管理してるの
450VM
400EC2+RDS
All ubuntsu
社員のほしいものに応じてインスタンスを立てて、なんでも作るスタンス。
でも No とも言うよときどき。
CI はどうしてるの？provisioning はどうしてる？
なるべく自動化はしているけど。まだ手動もある。
puppet 使っていて、リポジトリは Bitbucket
設定ファイルの管理方法
すべて puppet で管理していた、
でも遅くなることがわかったので
オペレーションとアプリの管理を別にした。
アプリは Bamboo で、OS 系とかほかは puppet で管理。
設定の変更はサービスデスクで受け付けている。
作成されたチケットから Bitbucket でブランチ切ってプルリク、その内容を Peer レビューする。
監視ツールはどうしている？
nagios,puppet
nagios は Confluence と連携していて、エラー内容と連携した解決ページが連携している
アラートはすべて HipChat にながしてるよ
nggios からは引っ越す予定
このアラート内容の解決策が書いてある Confluence ページと、
アラート項目が連携しているのはすごいな！
かなり欲しい連携機能。
インスタンスはどう分けてる？
20%は空いているようにしてるよ
社内システムは AWS ではなく、全部データセンター
Atlassain が落ちた時どうしてる？
常に Thread dump, Heap dump を管理することで Puppet で取得している。
アプリが落ちていれば、Heap dump を見てスタートとか。
Heap dump のパス設定を入れておけばスペースを確保できる。
一番多い落ちる理由はアドオンかバグ（dogfooding）
ドイツ製のアドオンがよく落ちる原因になっているらしいよ。
- Java のスレッドダンプ、ヒープダンプの取り方 - Qiita
- Thead dump, Heap dump についてはこちらで
VM と AWS はどっちが多い？
VM は筐体が古くなっているので AWS には行きたい
でもヘビーなのは VM で残す。軽いのは AWS へ移行。
感覚的には VM よりも AWS のほうがいい印象を受ける。