osc2016-tokyo/fall に参加した

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を超えるようになった場合、解析サーバを分割したほうがよいとのこと。
複数サイトからのログを集約することも可能。

メニューを閉じる