osc2016-tokyo/fall に参加した
その時のメモ
Debian updates – 岩松 信洋さん
・LinuxカーネルでなくFreeBSDやGNU/Hurdのカーネルを利用したものも提供
・63カ国、1000名のDebian公式開発者
・debian9は2017年Q2orQ3予定
Debian updates
・2016年2月からどういう変化があったか？をポイントに説明
2016/4/2 2016年度 Debian Project Leader 決定
2016/5/15 ZFSがcontribセクションに追加
2016/8/16 Debian23歳に
…
Debian7LTSは 2018/5/31まで
Debian9について
・Debian9ではサポートがi686以降に変更
古いx86のCPUはサポートされないかも
・Debugシンボル用パッケージ用新規スイート提供開始(debian9をapt-lineに入れると利用可能)
パッケージごとにdebugシンボルが入るかどうか決まっていたが、今後はすべてのパッケージにdebugシンボルが入る予定らしい
・Linuxカーネル4.10
・PHP7.0.12
・MariaDB 10.0.28
・OpenSSL 1.1.0
今後について
2016/11/5 transitions freeze ライブラリの変更禁止
2017/1/5 soft freeze パッケージのアップデート禁止
2017/2/5 full freeze
その他
2016/12/10 debian miniconf in Japan
Fluentd + Zabbix + Grafana で監視システムを構築してみよう – 盛 宣陽さん（SRA OSS, Inc. 日本支社）
Grafanaとは
Zabbix elastic influxDB CloudWatch などツールの使い分けが複雑に
→Grafana(グラフ作成ツール)で一箇所で見られるようにできるかも
・フロントはJavaScript、バックエンドはGoで書かれている
・2016/5/11 メジャーバージョン3.0 リリース(4.0ではslackやメールでの通知機能が追加される予定)
・debianへのインストールも簡単にできそう
GrafanaとZabbix連携
GrafanaにZabbixユーザを登録して閲覧できるように
(GrafanaのデータソースにZabbixを登録)
Grafana利用時のメリット
・クラウドとオンプレミス、2つの監視機構がある場合に、1箇所で閲覧できる
・スナップショット機能を利用して、過去のデータを保持できる(zabbixではデータ保持期間を過ぎると削除される)
・Annotation機能を利用して複数グラフを1箇所にまとめられる
はてなのサーバ/インフラを支える技術 ～ 2016新卒編 ～ – 佐々木 健人さん・古川 雅大さん
広告配信について
レイテンシ：リクエスト処理にかかる時間
スループット：単位時間あたりのリクエスト処理能力
50 msec or die(広告業界基準)
→負荷試験ツールを導入(Gatling)
→ボトルネックの把握(top,perf,pt-query-digest,NYTProf(perl)などのプロファイラを利用)
高速かつ冗長的なネットワーク構成にするために
ロール間は基本的にLBを通す
・LinuxLVS + Keepalived を使用
→NAT方式(戻りパケットが集中するため捌けるコネクション数が少ない、IPヘッダの書き換えで遅い)
DR方式(MACアドレスを書き換えるため高速、ただしARPを利用しているためネットワーク越えが難しい)
TUN方式(あたらしいIPヘッダを付与して、ネットワーク越えができるようにしている)
→はてなでは、TUN方式が多い(他での使用例はあまり聞いたことがない)
基盤技術の選択
必要な要件、インフラ事情は各社異なるので適材適所、無理し過ぎない選択を心がけるべし
(周りや流行りに振り回され過ぎないこと)
参考
https://speakerdeck.com/yuukit/linux-network-performance-improvement-at-hatena
【パネルディスカッション】今こそ改めて考える！OSSによるクラウド運用の勘所
※ほぼすべてさくらインターネットさんがおっしゃっていたこと。
オープンソースの監視ツールを導入してよかったこと
HobbitやXymonをZabbixに置き換えている
自動化がしやすい(障害検知したらアクションスクリプトを実行するなど)
日本語情報が多くある
うまくいっていること、うまくいかなかったこと
置き換えにあたり、1サーバあたり3000台監視していたが性能問題が発生した
→同じ問題が起こっている場所があり、その場合はDBチューニングやZabbixであればHouseKeeperでのチューニングを実施
正解がない運用で、何を正解だと考えて運用しているか
データセンター事業者としては「ハードが壊れた時だけ人が動く運用が正解」かと。
共有サーバでの特定ユーザがリソースを使いまくるような行為は、CPU監視などの挙動で判断できる。
不要なアラートを減らし、本当の障害が起きた時にアラートをあげることが正解だと考えている。
すべて監視サーバに役割を多くもたせ過ぎない。例えばサービスごとにZabbixを準備するなど分散できるようにしておく。
障害時チケット管理と、早く対応する工夫
・Redmineを利用。
・メールで対応。一次対応者が対応できる範囲を拡げる。
展示ブース
株式会社サードウェアさん
drbdmanage：drbd9で追加された機能。複数ノードの管理を簡単にしてくれるツールらしい。
SDSに向かっている印象を受けた。
サイトブリッジ株式会社さん
自治体用CMSを作成している。
走りは島根CMS。徳島県でもCMSを利用したいということでJoururiを制作。
承認システムなど通常のCMSとは異なる仕様が多々ある。
Joururiから派生して、ZOMEKIが作成されている。
日本Piwikユーザー会さん
リアルタイムアクセス解析プログラム。
月1000万PVを超えるようになった場合、解析サーバを分割したほうがよいとのこと。
複数サイトからのログを集約することも可能。