本番環境でのLispの使用

Grammarlyでは、ビジネスの中核である中央言語エンジンがCommon Lispで記述されています。 現在、このエンジンは1秒間に1,000を超える文を処理し、水平方向に拡張し、ほぼ3年間にわたって確実に生産に役立っています。



最新のクラウドインフラストラクチャにLispソフトウェアを展開することに関する投稿がほとんどないことに気づいたので、経験を共有することをお勧めします。 Lispのランタイムおよびプログラミング環境は、本番システムをサポートするためのいくつかのユニークで少し変わった機能を提供します（せっかちなものについては、最後の部分で説明します）。

Wut Lisp？!!

一般的な考えに反して、Lispは本番システムを作成するための非常に実用的な言語です。 一般的に、私たちの周りには多くのLispシステムがあります。Hipmunkの航空券を探しているとき、またはロンドンで地下鉄に乗っているときは、Lispプログラムが使用されます。



私たちのLispサービスは、概念的には、言語学者や研究者によって作成された膨大な知識の山で動作する古典的なAIアプリケーションを表しています。 使用される主なリソースはCPUであり、ネットワークのコンピューティングリソースの最大の消費者の1つです。



システムは、AWSにデプロイされた通常のLinuxイメージで実行されます。 生産にはSBCLを使用し、ほとんどの開発マシンではCCLを使用しています。 Lispを使用する楽しい瞬間の1つは、さまざまな長所と短所を持ついくつかの開発された実装から選択する機会があることです：私たちの場合、サーバーでの作業速度と開発中のコンパイル速度を最適化しました（これは私たちにとって重要です、後述）。

見知らぬ土地の見知らぬ人

Grammarlyでは、多くのプログラミング言語を使用してサービスを開発しています。JVMおよびJavascriptの言語に加えて、Erlang、Python、Goでも記述しています。 適切なサービスのカプセル化により、タスクに最適な言語またはプラットフォームを使用できます。 このアプローチにはサービスの価格がありますが、規則とパターンよりも選択と自由を重視しています。



また、言語に依存しないシンプルなインフラストラクチャユーティリティにも依存しようとします。 このアプローチは、このすべてのテクノロジー動物園をプラットフォームに統合する際の多くの問題から解放されます。 たとえば、statsdは、非常に使いやすい非常にシンプルで便利なサービスの優れた例です。 もう1つはGraylog2で、ロギングのスマートな仕様を提供します。CLで使用するための既製のライブラリが存在しないにもかかわらず、Lispエコシステムで利用可能なものからアセンブルするのは非常に簡単でした。 必要なすべてのコードは次のとおりです（そして、ほとんどすべてが仕様の単語翻訳の単なる単語です）。

(defun graylog (message &key level backtrace file line-no) (let ((msg (salza2:compress-data (babel:string-to-octets (json:encode-json-to-string #{ :version "1.0" :facility "lisp" :host *hostname* :|short_message| message :|full_message| backtrace :timestamp (local-time:timestamp-to-unix (local-time:now)) :level level :file file :line line-no }) :encoding :utf-8) 'salza2:zlib-compressor))) (usocket:socket-send (usocket:socket-connect *graylog-host* *graylog-port* :protocol :datagram :element-type '(unsigned-byte 8)) msg (length msg))))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

エコシステムにライブラリがないことは、Lispに対するよくある不満の1つです。 ご覧のとおり、この例では、5つのライブラリがエンコード、圧縮、Unix時間の受信、接続ソケットなどに使用されています。



Lispライブラリは存在しますが、すべてのライブラリ統合と同様に、問題が発生します。 たとえば、Jenkins CIを接続するには、xUnitを使用する必要があり、その仕様を見つけるのはそれほど簡単ではありませんでした。 幸いなことに、 Stackoverflowに関する 1つの質問が役に立ちました。最終的に、私たちはそれをテストすべきテストライブラリに組み込みました。



もう1つの例は、機械学習モデルを共有するためのHDF5の使用です。低レベルのhdf5-cffiライブラリを現実に適応させるのに少し時間を費やしましたが、現在のバージョンのCライブラリをサポートするためにAMI（Amazon Machine Image）の更新により多くの時間を費やさなければなりませんでした。



Grammarlyプラットフォームで従うもう1つの原則は、さまざまなサービスを最大限に分解して、水平方向のスケーラビリティと機能の独立性を確保することです。これは私の同僚の投稿です 。 したがって、言語コアサービスの重要な部分でデータベースと対話する必要はありません。 ただし、内部ストレージにはMySQL、Postgres、Redis、およびMongoを使用し、 CLSQL 、 postmodern 、 cl-redis、およびcl-mongoを使用してLispからそれらにアクセスしました。



Quicklispを使用して、外部の依存関係と、独自のライブラリとフォーク用のプロジェクトを備えたシンプルなライブラリソースコードパッケージシステムを管理します。 Quicklispリポジトリには、1000個を超えるLispライブラリが含まれています。これは非常に大きな数ではありませんが、本番環境のすべてのニーズを満たすには十分です。



実稼働環境での展開には、ユニバーサルスタックを使用します。Jenkinsを使用してアプリケーションをテストおよび構築し、 Rundeckのおかげでサーバーに配信し、 Upstartを介して通常のUnixプロセスとして起動します。



一般に、Lispアプリケーションをクラウドの世界に統合するときに直面する問題は、他の多くのテクノロジーで遭遇する問題と根本的には異なりません。 実稼働環境でLispを使用し、Lispコードの作成を楽しみたい場合、技術的な理由はありません。

私が今までデバッグした中で最も難しいバグ

この物語がどれほど完璧であっても、虹とユニコーンだけではありません。



難解なアプリケーションを作成し（Lispの世界の標準でも）、その過程でいくつかのプラットフォームの制限にぶつかりました。 そのような驚きの1つは、コンパイル時にメモリ不足になることでした。 私たちはマクロに大きく依存しており、そのうちの最大のものは数千行の低レベルコードに拡張されます。 SBCLコンパイラは多くの最適化を実装しているため、かなり高速に生成されたコードを楽しむことができますが、それらのいくつかは指数関数的な時間とメモリを必要とします。 残念ながら、それらをオフにしたり調整したりする方法はありません。 これにもかかわらず、よく知られた一般的な解決策であるcall-with- *スタイルがあります。これにより、モジュール性（このケースでは決定的であることが判明）とデバッグのために効率を少し犠牲にすることができます。



ガベージコレクターを調整して遅延を減らし、システムのリソース使用率を改善することは、コンパイラーを使いこなすのとは異なり、予想外の問題ではありません。 SBCLは、JVMほど高度ではありませんが、世代に優しいガベージコレクタを提供します。 世代のサイズを調整する必要があり、最適なオプションはより大きなヒープを使用することであることが判明しました。アプリケーションは2から4ギガバイトのメモリを消費しますが、25Gのヒープで起動し、自動的に第1世代のサイズが増加しました。 私たちがしなければならなかったもう1つのセットアップは、N分ごとにプログラムでGCを開始することでした。 ヒープの増加に伴い、数十分間にわたってメモリ使用量が徐々に増加していることがわかりました。これにより、GCに費やされる時間が増え、アプリケーションのパフォーマンスが低下しました。 定期的なGCを使用したアプローチにより、システムはほぼ一定のメモリ消費でより安定した状態になりました。 左側では設定なしでシステムがどのように動作するかを確認でき、右側では定期的なGCの効果を確認できます。







これらすべての困難の中で、私が遭遇した最も不快なバグはネットワークのバグでした。 このような状況で通常起こるように、バグはアプリケーションではなく、 基盤となるプラットフォーム （今回はSBCL）にありました。 さらに、2つの異なるサービスで2回彼に出くわしましたが、初めてそれを理解できなかったため、回避する必要がありました。



本番環境のかなりのワークロードでサービスの起動を開始したばかりのとき、通常の機能がしばらく続いた後、すべてのサーバーが突然遅くなり、最終的に利用できなくなりました。 入力が疑われる長時間の調査の結果、問題は低レベルのSBCLネットワークコードの競合、特にスレッドセーフではないソケット関数getprotobynameの呼び出し方法にあることがわかりました 。 非常にまれなレースであったため、この関数が何万回も呼び出されたときに、負荷の高いネットワークサービスでのみ現れました。 これにより、ワークフローが次々にノックアウトされ、徐々にシステムがcom睡状態になりました。



残念ながら、これをライブラリとしてより広いコンテキストで使用することはできません。 （バグはSBCLチームに送信され、修正されましたが、念のため、このハックを引き続き使用しています:)

 #+unix (defun sb-bsd-sockets:get-protocol-by-name (name) (case (mkeyw name) (:tcp 6) (:udp 17)))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

未来に戻る

Common Lispシステムは、伝説的なLispマシンの多くのアイデアを実装しています。 最も顕著なものの1つは、SLIMEインタラクティブ環境です。 業界ではLightTableおよび同様のツールの成熟を期待していますが、Lispプログラマーは長年にわたってSLIMEのこれらの機能を静かに楽しんでいます。 この重武装され機能している戦闘ステーションの力をご覧ください。



しかし、SLIMEはIDEに対するLispのアプローチだけではありません。 クライアント/サーバーアプリケーションであるため、リモートマシンでバックエンドを実行し、ローカルのEmacs（または、SLIMVを使用しない場合はVim）からバックエンドに接続できます。 JavaプログラマーはJConsoleについて考えるかもしれませんが、ここでは事前定義された一連の操作に制約されず、必要に応じて内省または変更を行うことができます。 これらの機能がなければ、ソケットの機能の競合をキャッチすることはできません。



さらに、SLIMEが提供する有用なユーティリティはリモートコンソールだけではありません。 多くのIDEのように、関数のソースコードに入ることができますが、JavaやPythonとは異なり、マシンにSBCLソースコードがあります。そのため、実装のソースコードをよく見ます。ボンネットの下。」 ソケットバグの場合、これはデバッグプロセスの重要な部分でもありました。



最後に、イントロスペクションとデバッグに使用するもう1つの非常に便利なユーティリティはTRACEです。 プログラムのデバッグに対するアプローチが完全に変わり、面倒なコード実行を段階的に行う代わりに、全体像を分析できます。 このツールは、ソケットバグのローカライズにも役立ちました。



トレースでは、トレースする関数を指定し、コードを実行すると、Lispはこの関数へのすべての呼び出しとその引数、および返されるすべての結果を出力します。 これはスタックトレースのようなものですが、完全なスタックを必要とせず、アプリケーションを停止せずに動的にトレースストリームを取得します。 トレースはステロイドの印刷のようなもので、複雑なコードの内部をすばやく突き抜けて、プログラムの複雑なパスを追跡できます。 唯一の欠点は、マクロをトレースできないことです。



これは、サービスの1つに対するJSONリクエストが正しく生成され、目的の結果が返されることを確認するために今日行ったトレースのフラグメントです。

 0: (GET-DEPS ("you think that's bad, hehe, i remember once i had an old 100MHZ dell unit i was using as a server in my room")) 1: (JSON:ENCODE-JSON-TO-STRING #<HASH-TABLE :TEST EQL :COUNT 2 {1037DD9383}>) 2: (JSON:ENCODE-JSON-TO-STRING "action") 2: JSON:ENCODE-JSON-TO-STRING returned "\"action\"" 2: (JSON:ENCODE-JSON-TO-STRING "sentences") 2: JSON:ENCODE-JSON-TO-STRING returned "\"sentences\"" 1: JSON:ENCODE-JSON-TO-STRING returned "{\"action\":\"deps\",\"sentences\":[\"you think that's bad, hehe, i remember once i had an old 100MHZ dell unit i was using as a server in my room\"]}" 0: GET-DEPS returned ((("nsubj" 1 0) ("ccomp" 9 1) ("nsubj" 3 2) ("ccomp" 1 3) ("acomp" 3 4) ("punct" 9 5) ("intj" 9 6) ("punct" 9 7) ("nsubj" 9 8) ("root" -1 9) ("advmod" 9 10) ("nsubj" 12 11) ("ccomp" 9 12) ("det" 17 13) ("amod" 17 14) ("nn" 16 15) ("nn" 17 16) ("dobj" 12 17) ("nsubj" 20 18) ("aux" 20 19) ("rcmod" 17 20) ("prep" 20 21) ("det" 23 22) ("pobj" 21 23) ("prep" 23 24) ("poss" 26 25) ("pobj" 24 26))) ((<you 0,3> <think 4,9> <that 10,14> <'s 14,16> <bad 17,20> <, 20,21> <hehe 22,26> <, 26,27> <i 28,29> <remember 30,38> <once 39,43> <i 44,45> <had 46,49> <an 50,52> <old 53,56> <100MHZ 57,63> <dell 64,68> <unit 69,73> <i 74,75> <was 76,79> <using 80,85> <as 86,88> <a 89,90> <server 91,97> <in 98,100> <my 101,103> <room 104,108>))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、ひどいソケットバグをデバッグするには、SBCLネットワークコードを深く掘り下げて呼び出された関数を調べ、SLIME経由で死にかけているサーバーに接続し、これらの関数を1つずつトレースする必要がありました。 そして、私は戻ってこなかった電話を受けたとき-それでした。 その結果、マニュアルで関数がスレッドセーフではないことを発見し、SBCLソースコードのコメントでそれに関するいくつかの言及を満たした後、自分の仮説を確信しました。



この記事は、Lispが私たちの最も重要なプロジェクトの1つに対して驚くほど信頼できるプラットフォームであることがどのように証明されたかについてです。 最新のクラウドインフラストラクチャの一般的な要件に完全に準拠しており、このスタックはあまり広く知られておらず人気があるという事実にもかかわらず、独自の長所があります。使用方法を学ぶだけで十分です。 複雑な問題を解決するLispアプローチの力について、私たちは何を言うことができますか。 しかし、これは全く異なる話です...



ご注意 翻訳者：

CISの人々が本番環境でのCommon Lispの使用について書いていること、そしてCISの人々でさえ書いていることを二重に嬉しく思います。 この記事を読んだ後、誰かがこの非常に過小評価されている技術に注意を払うことを願っています。