yumetodoの旅とプログラミングとかの記録

旅や登山の記録やプログラミング関連の話とかフリーソフト紹介とか

コアってなに?スレッドが2つある?非同期?というあなたに

前提: 演算器

例えばAND回路とかOR回路なんかをイメージしてほしい。

まずCPUがある

一般にCPUは1つのPCに1つのものをよく見かけるが、複数CPUが乗っていることもある。

コアとは

CPUは多数の演算器が複雑に組み合わさってできているが、この脳みそに当たるものが1つのCPUの中に複数あることがある(というかそのほうが主流)。これがコアだ。

Pipeline

基本的にコア1つに付き1つの作業しか同時にできない。はずであった。しかし、作業内容をCPUが見抜いて、依存関係のない演算同士をばらしてPipelineを組み立て、同時に複数の処理を実行するという離れ業を現代のCPUはやってのける。

ただし、例えば条件分岐では、分岐するまでパイプライン進められなくなる。パイプラインを崩す。

条件分岐予測とか投機的実行

パイプラインが崩れると処理速度が遅くなって困るので条件分岐に対しては条件分岐予測というものがある。

つまり、CPUの謎パワーで条件分岐先を予測して、投機的実行(Pipelineを組み立て分岐先の処理を実行)してしまう。条件分岐判定が終わって予測が間違っていたら処理を差し戻して正しい処理を実行する。

この投機的実行の有用性が揺らぐ事件としてSpectreがある。雑に解説すると、処理の差し戻しが不完全なことで意図しない副作用が起きるというものである。まじでどーすんだこれ。

SMT(同時マルチスレッディング)

Pipelineとは別に、基本的にコア1つに付き1つの作業しか同時にできないという概念を覆すものがある。1つの作業中のCPUをよく観察すると、すべての回路が仕事をしているわけではなかった。遊んでいるところでもう1個仕事できるんじゃないか?例えるならば右手でスマホを操作しながら左手で飲み物を飲めるようなものだ。

いわゆる論理コア。

論理コア

Intel® Hyper-Threading Technology

SMTの実装例である。1つのコアを2つのコアに見せかける。HTT。Technologyは冗長だから省いてHTと呼んだりハイパースレッディングと呼んだり。

プロセス

一気にソフトウェア面での話になってくる。

実行ファイルを実行する時にOSが生成し管理する。

一般的なOSでは当たり前のようにプロセスは複数作れる。

スレッド

プロセスごとにスレッドを生成できる。プロセスではメモリー空間を共有するのが難しい。スレッドならメモリー空間は共有だ(ただしバグを作り込みやすい)。スレッドの生成コストは普通プロセスの生成コストより小さい。

スレッドプール

プログラミングの技法的な話になってくる。スレッドは確かにプロセスの生成コストより小さいかもしれないがそれでも重い。ループの中で逐次スレッドを生成しては破棄するような使い方をすると遅すぎる。ここで生産者ー消費者モデルというプログラミングの技法を使う。つまり予めいくつかのスレッドを生成しておき休眠させ、必要になったら起こしてデータを渡して処理を行わせ、終わったら次のデータが来るまでまた眠る。これがスレッドプールだ。

非同期

スレッドプールをまともに実装するなんてことができるのは一部のプログラマーだけだ。一般的なプログラマーには無理だし、そうでなくても楽をしたい。生産者ー消費者モデルではなく、ある処理が終わったときに呼び出す処理(callback)を登録しておくという手法を用いるほうがわかりやすい。これが非同期プログラミングだ。

futhre/thenとかasync/awaitとか

非同期プログラミングはスレッドプールを自分で書くよりはマシかも知れないが、プログラムの可読性が落ちる(callback地獄)。そこでライブラリ側でこれをどうにかする手法としてfuture/thenだったり、これをもうすこし可読性を上げて書けるようにするプログラミング言語仕様側のサポートとしてasync/awaitとかが一部のプログラミング言語にはある。

「スレッドと呼ばれるものが2つある問題」

プロセスごとにスレッドがあるのだが、一方でSMTの論理コアのことをスレッドと呼ぶことがある。プロセスごとのスレッドを論理コアにOSが割り当てるのだからThreadingのほうが正しいはずなのだが、どういうわけか論理コアのこともスレッドと呼ぶ。意味がわからない。

謝辞

質問者
情報提供

ようやくこのブログをHTTPS化した

はてなブログHTTPS化の状況

はてなブログHTTPS化の状況はちょっと遅かった。

staff.hatenablog.com

2017年9月25日に全ページHTTPS化に向けたロードマップが出た。

しかし作業は当初見積りより遅れ、

blog.hatenablog.com

staff.hatenablog.com

2017年11月20日に管理画面がHTTPS化、第一段階が終わった。

staff.hatenablog.com

2018年2月22日にようやく第二段階のはてな提供ドメインのブログHTTPS化がアナウンスされたが、これは全ユーザー一斉ではなく順次だった。

つい最近になってようやくHTTPS化の対象になったのでHTTPS化した。

HTTPS化の瞬間

HTTPS

ポチッとな。

テーマ側の対応

検索ボックスのアイコン

このブログはテーマを自作しているのでそっちの対応も必要だ。まあもともとHTTPS化の流れを知っていた私に隙はない(キリッ

・・・とか思っていたがそうでもなかった。あやややや。

yumetodo.hateblo.jp

でも述べたとおり、自作テーマははてなが提供しているBoilerplateをforkして作っているのだが、そのはてな提供部分が問題だった。

検索ボックスの検索アイコンは、CSSbackground-imageで実現しているのだが、それがどのようになっていたかというと、

https://github.com/hatena/Hatena-Blog-Theme-Boilerplate-Less/blob/9bf81a62aa2804f27b96c79ea34bebfa6b1f4630/boilerplate.less#L561

    .search-module-button {
        width: 20px;
        height: 20px;
        background: transparent url(http://blog.hatena.ne.jp/images/theme/search.png) no-repeat right center;
        border: none;
        outline: none;
        text-indent: -9999px;
        position: absolute;
        top: 5px;
        right: 5px;
        opacity: 0.5;
        &:hover {
            opacity: 0.85;
        }

のようにhttpから始まるURLの画像が指定されていた。これはPull Requestチャンスだな!と思って

make HTTPS to avoid mixed contents by yumetodo · Pull Request #16 · hatena/Hatena-Blog-Theme-Boilerplate-Less

を投げたのだが、よく見たら

github.com

あれ~、開発終了している・・・。まじか。どうも

github.com

lessをやめて、sassに移行したらしい。は?意味がわからん。一体 @ueday氏(はてなの中の人?)は何をやってるんや???

まあそれはいい。で、そのsassの方の該当部分はどうなっとるんじゃろなと思ってみると、

    .search-module-button {
        width: 24px;
        height: 24px;
        margin-right: 5px;
        background: transparent url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 20 20'%3E%3Cdefs%3E%3Cstyle%3E.a%7Bfill:none;%7D%3C/style%3E%3C/defs%3E%3Ctitle%3Esearch%3C/title%3E%3Cpath d='M16.7,15l-3.4-3.3h-.1a5.4,5.4,0,0,0,.9-3.1,5.6,5.6,0,1,0-5.6,5.6,5.4,5.4,0,0,0,3.1-.9.1.1,0,0,0,.1.1L15,16.7a1.1,1.1,0,0,0,.8.3,1.6,1.6,0,0,0,.9-.3,1.4,1.4,0,0,0,0-1.7M8.5,12.3A3.8,3.8,0,0,1,4.8,8.5,3.8,3.8,0,0,1,8.5,4.7a3.9,3.9,0,0,1,3.8,3.8,3.8,3.8,0,0,1-3.8,3.8'/%3E%3Crect class='a' width='20' height='20'/%3E%3C/svg%3E") no-repeat center;
        background-size: 20px 20px;
        border: none;
        outline: none;
        color: transparent;
        overflow: hidden;
        opacity: .5;
        cursor: pointer;
        &:hover {
            opacity: .85;
        }
}

インラインSVGになっていた

まあそっちのほうがいいかってことでこちらも追従した。

github.com

CIを直す

自作テーマはCIで自動デプロイしているんだが、このCIが前から壊れていた。原因はテーマのハックに使っているJavaScriptをminify&ugrifyするGoogle Closure CompilerがJava7で動かなくなったためらしい。Shippableのコンテナに入っているのは

Overview - Shippable Docs

によればv6.3.4のイメージのハズだから、

v6.3.4 - Shippable Docs#nodejs

Java 1.8.0が入っているはずなのだが、どうもjava -versionする限りでは1.7が入っている。

やってられんのでdocker imageを指定してやることにしようとしたが、その迷走の過程で

aaaaaaaa

大量のcommitを濫造した。うへぇ・・・。

ついでにClosure Compilerのinstall scriptに使ってたfs-promiseがいつの間にかdeprecatedになってたのでfs-extraを使うように直したり、その他Node.jsのdependencyを更新したりして、

app.shippable.com

どうにかCIが通った。

本当は本家がlessからsassに移行したのに追従してこっちもsassにするべきなんだろうけど、だるいのでやめた。

記事のMixed Contentsとの戦い

まあもともとHTTPS化の流れを知っていた私に隙はない(キリッ

・・・と思ったがこちらもやはり穴があったようで数箇所httpなコンテンツを読み込んでいた。

まあ修正箇所は多くないし全部単純な置換で済んだので良かった。

よく言われるHTTPS化のメリットについて検証

鍵マークがつく

Mixed Contentsを全部潰したところ、ついた。なんか気持ちいい。

http2対応による対応ブラウザで表示速度アップ

速いと噂のhttp2を使うにはHTTPS化が前提になる。

http2対応していないブラウザとかもう絶滅しているのでいいとして(IE11ですら対応している)、はてな側でhttp2対応しないと意味がない。

見た感じまだまだ全然http2対応していないのでまあ当然速度アップとかない。

・・・というかそもそもはてなブログは読み込むものが多すぎてhttp2対応しても効果が吹き飛びそう

SEO

もともと急にどうこういう話でもないし、そんなに大きなfactorでもないし気にしない。

終わりに

  • ようやくこのブログをHTTPS化した
  • Shippableの挙動がなんか気まぐれ
  • @ueday氏(はてなの中の人?)はなぜlessを捨ててsassに移ったのか?謎い。

サーバー監視ツール netdataをVPSのUbuntu16.04に導入した

はじめに

今IDCFクラウドVPSを借りていて、鯖管初学者として私、 @kamioda_ampsprg, @celluloce@qiitadon.comと割り勘してえっちらおっちら運用している。

先日は@kamioda_ampsprgが

qiita.com

のような記事を投稿していた。

サーバー監視ツールを入れたい

gnome-system-monitor

最初は適当にgnome-system-monitorみればええんちゃうん?とか軽く考えていたが、入れようとしたらご覧の有様だよ!

流石にそっ閉じして、真面目にサーバー監視ツールを入れようとなった。

netdata

qiita.com

というわけでnetdataである。

github.com

公式Wikiに基づいて

bash <(curl -Ss https://my-netdata.io/kickstart.sh)

とした。

これだけでsystemdのサービス追加とか不足パッケージ引っ張ってきたり、cronに自動アップデート登録したりしてくれる。強いて言えばcronじゃなくてsystemdで自動アップデートしてほしかったが、まあいいことにする。

この時点で、http://127.0.0.1:19999でWeb画面が見えることになっているが、ここで19999 port開けるとかただの馬鹿なのでもっとマシな手段を取る。

サブドメイン取得

www.onamae.com

お名前.comのDNSを使っているので、それで新たにAレコードを貼る。

DNS A

Let's Encrypt

とりあえず

<VirtualHost *:80>
        ServerName netdata.irregular-at-tus.work
        ServerAdmin https://qiitadon.com/@yumetodo
        DocumentRoot /usr/share/netdata/web/
        ErrorLog /home/for_netdata/logs/error.log
        CustomLog /home/for_netdata/logs/access.log combined
</VirtualHost>
<Directory /usr/share/netdata/web>
        Options Indexes
        Options FollowSymLinks
        #AllowOverride none
        Require all granted
</Directory>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

のようなダミーのApache2 configを書いて/etc/apache2/sites-availableに置き、

$ sudo systemctl restart apache2
$ ./certbot-auto run --apache -d netdata.irregular-at-tus.work

certbot

--apacheは自動でapache2の設定を書き換えて証明書のパスを書いたりしてくるはずなんだけど、どうにもうまくいかない。なんでや。

まあ証明書はくれたのでいいことにする。

Digest認証有効でHTTPSでnetdataの画面を公開する

あんまりサーバー監視ツールの画面を不特定多数の人には見られたくない。アクセスする人のIPアドレスは可変なのでIP指定制限するのもだるい。BASIC認証はダサい。どうするかと思っていたら、

qiita.com

ちょうどいい記事があった。そういやDigest認証なんてあったわ。

Apache2からSSL有効でProxy貼る方法は

github.com

公式のIssueにそれっぽいconfig晒している人がいたのでこいつを元にいじる。

<VirtualHost *:80>

    ServerName netdata.irregular-at-tus.work
    ServerAdmin https://qiitadon.com/@yumetodo

    DocumentRoot /usr/share/netdata/web/

    Redirect permanent "/" "https://netdata.irregular-at-tus.work/"

    ErrorLog /home/for_netdata/logs/netdata-error.log
    CustomLog /home/for_netdata/logs/netdata-access.log combined

</VirtualHost>

<VirtualHost *:443>

    ServerName netdata.irregular-at-tus.work
    ServerAdmin https://qiitadon.com/@yumetodo

    DocumentRoot /usr/share/netdata/web/

    SSLEngine On
    SSLCertificateFile    /etc/letsencrypt/live/netdata.irregular-at-tus.work/cert.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/netdata.irregular-at-tus.work/privkey.pem
    SSLProtocol all -SSLv2 -SSLv3
    Header set Strict-Transport-Security "max-age=31536000; includeSubDomains"

    ProxyRequests Off
    ProxyPreserveHost On

    <Proxy *>
        Require all granted
    </Proxy>

   # Local 127.0.0.1:19999 netdata server accessed with '/'
    ProxyPass "/" "http://127.0.0.1:19999/" connectiontimeout=5 timeout=30
    ProxyPassReverse "/" "http://127.0.0.1:19999/"

    <Location />
        AuthType Digest
        AuthName "Digest Auth"
        AuthUserFile /etc/apache2/.htdigest
        Require valid-user
    </Location>

    <FilesMatch "\.(cgi|shtml|phtml|php)$">
        SSLOptions +StdEnvVars
    </FilesMatch>

    <Directory /usr/lib/cgi-bin>
        SSLOptions +StdEnvVars
    </Directory>

    BrowserMatch "MSIE [2-6]" \
    nokeepalive ssl-unclean-shutdown \
    downgrade-1.0 force-response-1.0

    ErrorLog /home/for_netdata/logs/netdata-error.log
    CustomLog /home/for_netdata/logs/netdata-access.log combined

</VirtualHost>

https://gist.github.com/yumetodo/11ead23aee869f5f9ff7dfc4618c458e

こいつを/etc/apache2/sites-availableに置いて(さっきのと置き換える)

$ sudo a2dismod auth_basic
$ sudo a2enmod auth_digest
$ sudo systemctl restart apache2

で完了。注意点はBasic認証を殺さないとDigest認証は使えないらしい。

動作

Microsoft EdgeはDigest認証すらまともに使えない

なんとURL末尾に?をつける必要があるそうだ。糞では?

参考リンク